Context Navigation

← Previous Period
Next Period →

Timeline

Nov 24, 2022:

4:53 PM Ticket #3181 (Can't press Alt+Tab when HotKeySet - Alt+Esc) updated by Jos: Replying to tohatemp@…: > doesn't work > > Windows 10 64 bit Enterprise LTSC Evaluation Join the forum in case you want to discuss this first, but ticket remains closed.
1:46 PM Ticket #3181 (Can't press Alt+Tab when HotKeySet - Alt+Esc) updated by tohatemp@…: doesn't work Windows 10 64 bit Enterprise LTSC Evaluation
1:45 PM Ticket #3181 (Can't press Alt+Tab when HotKeySet - Alt+Esc) updated by tohatemp@…: doesn't work Windows 10 Enterprise LTSC Evaluation

Nov 16, 2022:

3:09 PM Ticket #3928 (WinWaitActive() prevents Raw Input's WM_INPUT messages from queueing ...) closed by J-Paul Mesnage: Works For Me
3:05 PM Ticket #3932 (_WinAPI_GetRawInputData Helpfile Example) closed by J-Paul Mesnage: Completed: Added by revision [12918] in version: 3.3.17.0
3:00 PM Ticket #3932 (_WinAPI_GetRawInputData Helpfile Example) updated by TicketCleanup: Version changed
Automatic ticket cleanup.
2:55 PM Ticket #3932 (_WinAPI_GetRawInputData Helpfile Example) updated by J-Paul Mesnage: for me is not a bug but a feature request …
2:55 PM Ticket #3932 (_WinAPI_GetRawInputData Helpfile Example) updated by J-Paul Mesnage: Type changed
11:41 AM Ticket #3932 (_WinAPI_GetRawInputData Helpfile Example) updated by J-Paul Mesnage: this can benefice to other examples I will work on it Cheers
8:41 AM Ticket #3932 (_WinAPI_GetRawInputData Helpfile Example) created by KaFu: Playing around with above example and wondering why nothing's …
6:44 AM Ticket #3931 (x86 compiled binaries miss DEP attribute) updated by anonymously: Replying to Jpm: > did you check with the latest version 3.3.16.1? Yes I tried with the latest version 3.3.16.1 and it has the same output regarding lack of DEP compliancy attribute

Nov 15, 2022:

5:48 AM Ticket #3931 (x86 compiled binaries miss DEP attribute) updated by J-Paul Mesnage: Owner, Status changed
5:48 AM Ticket #3930 (DllStructs created in one scope gets dropped if chained with a ...) closed by J-Paul Mesnage: No Bug
5:47 AM Ticket #3931 (x86 compiled binaries miss DEP attribute) updated by J-Paul Mesnage: did you check with the latest version 3.3.16.1?
2:56 AM Ticket #3931 (x86 compiled binaries miss DEP attribute) created by anonymously: Binaries compiled for x86 have DEP compliancy attribute set to false. …

Nov 14, 2022:

7:57 PM Ticket #3930 (DllStructs created in one scope gets dropped if chained with a ...) updated by anonymous: Thought so too, in which case I think this pitfall should probably be stated in the documentation, that the lifetime of DllStructs pertains to the scope where it is allocated, and so DllStructCreate when supplying a pointer will not count as valid references.
1:20 PM Ticket #3930 (DllStructs created in one scope gets dropped if chained with a ...) updated by J-Paul Mesnage: In fact your concern come from the fact that parameter pass to parseStruct() is a temporary variable. So how can you map a permanent area with the DllStructGetPtr() and get a valid result. That the reason why you get such behavior. I will close the ticket as No bug. Cheers
11:45 AM Ticket #3928 (WinWaitActive() prevents Raw Input's WM_INPUT messages from queueing ...) updated by J-Paul Mesnage: So, if I understand nothing to change, in a simple manner, inside AutoIt code Cheers
11:09 AM Ticket #3929 (Memory leak when returning struct members within With...EndWith) updated by J-Paul Mesnage: Fix, I sent a proposal to Jon

Nov 12, 2022:

10:59 PM Ticket #3928 (WinWaitActive() prevents Raw Input's WM_INPUT messages from queueing ...) updated by nurupo: I guess you are right, I shouldn't be blocking the message handler for so long. I just moved the *Responsive() calls out of the message handler and into the main While 1 loop: made OnMouseWheel() increment a new counter for each event received and the main While 1 loop decrement it, calling LessResponsive() in the While loop instead of the message handler. LessResponsive() no longer causes messages to be dropped and and the messages are now being queued by AutoIt, i.e. the script now behaves similar to how it behaved with MoreResponsive being called inside the message handler.

Nov 11, 2022:

10:54 PM Ticket #3929 (Memory leak when returning struct members within With...EndWith) updated by J-Paul Mesnage: Owner, Status changed

Nov 10, 2022:

2:15 AM Ticket #3928 (WinWaitActive() prevents Raw Input's WM_INPUT messages from queueing ...) updated by anonymous: Incidentally, the documentation for GUIRegisterMsg states: > Warning: blocking of running user functions which executes window messages with commands such as "MsgBox()" can lead to unexpected behavior, the return to the system should be as fast as possible !!!
2:11 AM Ticket #3928 (WinWaitActive() prevents Raw Input's WM_INPUT messages from queueing ...) updated by AutoXenon: Windows automatically assign message queues for each process/thread. The message stays in the queue/inbox until the program gets around to processing them. Autoit is singlethreaded, it stands to reason that it has to switch between message handling and executing the script, internally we don't know how it splits the processing time other than that the program needs to respond to the window messages in their inbox every so often otherwise the OS will think that it has frozen.

Nov 9, 2022:

8:09 PM Ticket #3928 (WinWaitActive() prevents Raw Input's WM_INPUT messages from queueing ...) updated by nurupo: While making a reply to you I have noticed a small copy-paste mistake I have made in the How to use the example section, specifically that the step (3) shouldn't be there, as the step (3) only happens when the *Responsive() calls are uncommented. I ended up improving the reproducible example -- it now does the mouse wheel scrolling for you, making the mouse scrolling more consistent as it no longer depends on a human, no longer mice-specific, etc. The improved example also needs an updated explanation. Here is the new reproducible example: […] = How to use the example = == LessResponsive() == 1. Open Notepad, run the script and click on SciTE to make the SciTE window active 2. The script will do 5 mouse wheel scrolls per second for you, for the duration of 5 seconds 3. You should see the script activating Notepad window, writing current @MSEC into it, and activating the SciTE window back over and over again 4. After 5 seconds, the script should terminate on its own 5. Check the console output to see how many scrolls per second the script's message handler received. (In my case it's just 1!) 6. Take note of the window wait time printed to the console, we will need that for MoreResponsive() later on. (19ms for me, but it's fine if your is different) Here is what my output for the comparison: […] Notice that while the scripts sends 5 mouse wheel scroll messages via MouseWheel(), it receives a lot fewer of them per second. On my PC I receive just 1 mouse wheel scroll message per second, i.e. the other 4 of WM_INPUT mouse wheel messages are not being delivered, they are being discarded by AutoIt. The final number I get is 5 messages received when 25 were sent, so 20 messages got discarded in those 5 seconds. == MoreResponsive() == 1. Comment out LessResponsive() 2. Uncomment MoreResponsive() 3. Pass into MoreResponsive() the window wait time from the console output you got when running LessResponsive() (e.g. I got 19ms, so I pass 19) 4. Open Notepad, run the script and click on SciTE to make the SciTE window active 5. You should see the script activating Notepad window, writing current @MSEC into it, and activating the SciTE window back over and over again 6. After 5 seconds, the script should terminate on its own 7. Check the console output to see how many scrolls per second the script's message handler received. (In my case it's 5) Here is what my output for the comparison: […] Now the script receives a lot more scrolls per second. On my PC I'm getting all 5 of them. That's a huge increase in responsiveness! Also note how by the end of it, all 25 out of 25 mouse scroll messages are received. == Message queueing == What is more, when using MoreResponsive() (or even having all of *Responsive() commented out), if you scroll faster than OnMouseWheel() can keep up with, Autoit will start queueing the unprocessed WM_INPUT messages. You can simulate this by setting $SCROLLS_PER_SECOND to, for example, 50. Because onMouseWheel() takes 79ms to run, the script can process at most 1000/79 = 12.66 mouse wheel scrolls per second, so 50 is definitely faster than OnMouseWheel() can keep up with. You can see that in the case of MoreResponsive(), once the script stops scrolling as indicated by "Stopped scrolling!" in the output, OnMouseWheel() continues to get called until all of the queued up messages are processed, running way beyond the 5 seconds. This doesn't happen with LessResponsive(), somehow WinWaitActive() prevented the messages from queueing up. === LessResponsive() === Here is what my output of LessResponsive() with $SCROLLS_PER_SECOND = 50: […] As you can see, it still processes just 1 message per second and doesn't queue anything. By the end, only 5/250 messages were received. === MoreResponsive() === Here is what my output of MoreResponsive() with $SCROLLS_PER_SECOND = 50: […] You can see that the script kept receiving mouse scroll messages way after it stopped sending them, it stopped scrolling at 14:43:57 but was still catching up with receding the scroll messages up to 14:44:13, and it only stopped receiving them because all 250 of them were received. The script also took 20 seconds to run, not 5. So clearly AutoIt is queueing the messages in the case of MoreResponsive(). In fact, AutoIt queues them by default, which you can verify by having both *Reponsive() commented out. But in the case of LessResponsive(), WinWaitActive() somehow breaks the queueing, it breaks the expected default behavior. --- With all that said, I ask that you look into why WinWaitActive() makes the application less responsive, specifically, why when using it I get 1) fewer WM_INPUT messages being delivered and 2) WM_INPUT messages not queueing up at all, and I hope that this issue gets resolved in some future AutoIt version, if possible. Sorry for so much text!
6:59 AM Ticket #3929 (Memory leak when returning struct members within With...EndWith) updated by J-Paul Mesnage: Reporter changed
6:58 AM Ticket #3930 (DllStructs created in one scope gets dropped if chained with a ...) updated by J-Paul Mesnage: Reporter changed
1:02 AM Ticket #3930 (DllStructs created in one scope gets dropped if chained with a ...) created by AutoXenon: Original thread: …
12:54 AM Ticket #3929 (Memory leak when returning struct members within With...EndWith) created by AutoXenon: Original thread: …