Because of the requirements for my application, my application
currently uses a message loop with three 'forks', used for
communication with my TWAIN webcam, LabWindows controls and everything
else (Windows, basically), respectively. For some reason, this does not
work correctly.
Everything starts with a PeekMessage(PM_NOREMOVE) which fills a message
structure but does not remove the message from the queue. For the TWAIN
fork, there is no problem: TWAIN requires me to send every message to
the Source Manager, which then tells me whether it was his or not.
Depending on that answer, I either check for a new message (after
removing this one) or continue processing the current one. If I
continue, I call GetUserEvent, check to see whether it has removed the
message from the queue (just to see if GetUserEvent actually did
something with the message), and if not, I process the message the
plain, old-fashioned Windows way: TranslateMessage() and
DispatchMessage().
After noticing that my application would hang on mouse clicks (there
would be no response after clicking a button, until I moved the mouse),
I started wondering whether the LabWindows events would actually show
on the message queue. After all, I was only running GetUserEvent
if PeekMessage had found anything.
To check this, I changed my message loop to be like this:
while(!PeekMessage(no wait, PM_NOREMOVE))
ProcessLabWindowsEvent();
//this is all I changed!
WaitMessage();
if(!CheckAndProcessTwainMessage)
//return value shows whether it was a TWAIN message or not, if it was, it has also been processed and removed from the queue
ProcessLabWindowsEvent
if(message has not been removed from queue)
ProcessWindowsEvent
Sure enough, the response to a mouse click is now immediate. This has
left me wondering: does this mean that LabWindows events are not
windows messages (that is, not only is it impossible to process them
with DispatchMessage, they aren't even stored on the message queue)?
That would mean that there is a seperate LabWindows queue which has no
relation whatsoever with the windows message queue.
To test this, I inserted code that would 'warn' me when GetUserEvent
returned a nonzero value while the message queue was empty (I used
GetQueueStatus for testing this), and some code that would 'warn' me
when GetUserEvent had removed a message from the message queue (which
is apparently the case when the topmost message has changed). To my
surprise,
both of these codes 'warned' me, which would mean
that some of the events are (or correspond to) windows messages and
some aren't (don't). Does anybody have some more information on this?
Also, it seems to me that the WaitMessage() would cause me to
temporarily ignore LabWindows events if they should happen immediately
after eachother without a TWAIN or Windows message between them,
causing my application to hang again. So far, I have not had any
problems with this. I guess the two events immediately after eachother
are an improbable scenario?
