GUI freezes if being moved while WinWaitNotActive is run

[Osprey]

I stumbled upon this earlier tonight and whipped up the simplest code to demonstrate it:

Code: Select all

Gui, New, -MinimizeBox, Test
Gui, Add, Text, x0 y10 w300 h50 Center, While moving this window around by the title bar, press Q.`nWhen it freezes, press Esc to exit the script.
Gui, Show, h50 w300, Test
Return

Esc::ExitApp
q::WinWaitNotActive, Test

Interestingly, the hotkey to kill the script still works, so it's not the process that's frozen, just the GUI. Along with the GUI being frozen, the mouse pointer gets locked out of entering the Windows taskbar area and from clicking on other apps. Keyboard commands (like Alt+Tab) work, though. Also, if I change the command to WinWaitActive, the window movement will noticeably stutter, but won't freeze the GUI. The same thing happens if I leave it as WinWaitNotActive and change the window title to wait for to something else (i.e. if the title match fails). Finally, the total freezing also happens with While WinActive("Test") and While WinExist("Test").

I ran into this because I have a script that sets a timer which, when it goes off, checks whether the GUI window is active, and I happened to be moving the window when the timer went off.

I should add that this is with v1.1.26.01 and I'm on Windows 10 x64.

Edit: If anyone stumbles upon this, a workaround that I've found is to simply precede the WinWaitNotActive line with If !(GetKeyState("LButton", "P")), so that it doesn't process it if the user is pressing the left mouse button, since he might be dragging the window around.

[lexikos]

That would be explained AutoHotkey's lack of multi-threading.

Although AutoHotkey doesn't actually use multiple threads, it simulates some of that behavior: If a second thread is started -- such as by pressing another hotkey while the previous is still running -- the current thread will be interrupted (temporarily halted) to allow the new thread to become current. If a third thread is started while the second is still running, both the second and first will be in a dormant state, and so on.

When the current thread finishes, the one most recently interrupted will be resumed, and so on, until all the threads finally finish.

[Osprey]

I don't think that that's the explanation because...

1) The script is not executing anything when the freezing happens. There's nothing to be interrupted.
2) No thread is responsible for the window being able to be moved around the screen. That's handled by Windows.

This isn't a case of AutoHotkey not being able to do two things at once. What you quoted refers to script execution halting. I'm talking about the GUI window, itself, freezing and leaving the user locked out of using Windows with his mouse indefinitely until he uses the keyboard to kill or de-activate it.

[lexikos]

Not exactly; the underlying design causes both for the same reasons.

When you start moving a window, the program (via system code) enters a "modal loop". Any new thread interrupts this loop in exactly the same manner that it would interrupt another quasi-thread. The loop is resumed when the thread finishes and returns, in the same manner that a previous quasi-thread would be resumed. The loop monitors the mouse and releases the mouse capture when the button is released. While the loop is suspended, no one will notice the button has been released, so the mouse will remain captured, but the window won't move because the loop isn't actively running.

I oversimplified because I don't like spending time explaining why I won't "fix" a "bug". Perhaps I should have simply stated that it is by design and I have no intention of adding a workaround.

[Osprey]

I didn't realize that you're the author or else I wouldn't have contradicted you like that. No offense meant. Thanks a lot for the explanation. It makes more sense now. I understand that these things are rarely "bugs," but you never know what the author is willing to "fix" unless you bring it up. I've been on the other side, myself, and told users that things were by design and not something that I was going to "fix," only to turn around and "fix" them, anyways . Anyways, cheers and thanks for such a useful utility.

[guest3456]

I don't think that that's the explanation because...

1) The script is not executing anything when the freezing happens. There's nothing to be interrupted.
2) No thread is responsible for the window being able to be moved around the screen. That's handled by Windows.

This isn't a case of AutoHotkey not being able to do two things at once. What you quoted refers to script execution halting. I'm talking about the GUI window, itself, freezing and leaving the user locked out of using Windows with his mouse indefinitely until he uses the keyboard to kill or de-activate it.

if you are willing to use AKH_H, you can do proper multi-threading. this works:

Code: Select all

Gui, New, -MinimizeBox, Test
Gui, Add, Text, x0 y10 w300 h50 Center, While moving this window around by the title bar, press Q.`nThen release the drag and bring another window active
Gui, Show, h50 w300, Test

NewThread := AhkThread("q::`nWinWaitNotActive, Test`nMsgBox, not active`nreturn")
Return

Esc::ExitApp

[Osprey]

if you are willing to use AKH_H, you can do proper multi-threading. this works:

Thanks a lot for the suggestion. I'd like to stick to regular AHK, though, since I want the tools that I release to the public to be easily modifiable and re-compilable by others. I can live with the limitations. I'll keep AHK_H in mind, though, if I ever discover a use that I absolutely can't use regular AHK for. Thanks.

[jeeswg]

Using ExecScript may be a workaround in AutoHotkey_L. Run a temporary second script.
Run / RunWait
https://autohotkey.com/docs/commands/Run.htm#ExecScript

[Helgef]

I ran into this because I have a script that sets a timer which, when it goes off, checks whether the GUI window is active, and I happened to be moving the window when the timer went off.

you should use ifwinnotactive instead of winwaitnotactive.

Cheers.

[Osprey]

Using ExecScript may be a workaround in AutoHotkey_L. Run a temporary second script.
Run / RunWait
https://autohotkey.com/docs/commands/Run.htm#ExecScript

Thanks. That's not suitable to my situation, though, since I want to keep the tool to a single, compiled script.

you should use ifwinnotactive instead of winwaitnotactive.

Thanks, but that doesn't accomplish the necessary waiting and I've already tried various loops that included WinActive().

I'm happy with the workaround that I mentioned earlier. I'm not really looking for any others anymore, but thanks anyways, guys.

[nnnik]

You should probably use OnMessage - it's definitively the cleanest solution for your problem.

[Osprey]

You should probably use OnMessage - it's definitively the cleanest solution for your problem.

Hey, you're right. WM_MOUSELEAVE handles that beautifully. I should've thought of that, since I'm using OnMessage (WM_MOUSEMOVE, specifically) to display the tooltips in the first place. Duh . Thanks, nnnik.