WaitOnMouseEvent fails when second thread is running

WaitOnMouseEvent fails when second thread is running

I am developing a Quickwin program that allows user input using either keystrokes or mousemovement. The technique is to have the main program process mouse movements using the (blocking) function WaitOnMouseEvent, while a second thread watches for keystrokes. I have modeled this using the sample program PeekApp. See attached.

I cannot get this to work properly. When the !! lines are commented (i.e. no 2nd thread) it works, reporting the mouse position every time it is moved. But if II lines are uncommented, a mouse movement only results in the status message "Mouse input pending in unit 5" and it is blocked until a keystroke is made. It appears to me that a GETCHARQQ statement in the second thread is blocking the execution of the first thread.

If I comment the WaitOnMouseEvent line, the program works fine: the (bogus) mouse position is reported every time through the loop, while any keystrokes made are detected by the second thread and reported.

Am I doing something wrong, or is this a bug, or is this behavior simply a limitation of Quickwin? The documentation implies it should work.

(btw, I tried to insert the main program MyPeekApp here but could not obtain suitable results--everything was double spaced with many unintended line breaks. How does one do this?)

Downloadapplication/octet-stream mypeekapp.f905.05 KB
Downloadapplication/zip mypeekapp.zip1.88 KB
3 posts / 0 new
Last post
For more complete information about compiler optimizations, see our Optimization Notice.

As far as I know, each GUI thread has its own message queue. And so, each thread should have its own message loop. I guess, your thread procedure GetCharProc needs to have one too.

Jörg Kuthe

Are you distinguishing "GUI thread" from other threads? I have not done anything special with message threads before, and the sample program PeekApp does not, although granted the threads in PeekApp are not GUI. In my adaptation the primary thread, which processes mouse events, runs fine as long as there is not a second thread. And the second thread, which processes keystrokes, is non-GUI.

Maybe you are right in general, but that Quickwin takes care of the message loops? And that for some reason Quickwin fails to do that in my case?

Leave a Comment

Please sign in to add a comment. Not a member? Join today