Earlier quoted context omitted.
I am familiar with the design of message queues, though not specifically with the design of Windows message pumps. > If you violate the run loop's threading requirements it's not totally inconceivable that a mouse event could affect behavior. That's true. But the possibility remains that the design of Windows message queues is so byzantine and imposes so many arcane requirements on the developer that it is easy to mi…
It looks more to me that there's some problem with the background polling mechanism in the app, as implied by solution #1. Presumably something in the mouse event handler does something that prods the polling code into life, perhaps because something somewhere is trying to update the list of things on screen in order to handle hovering. Kind of hard to say without looking at the code, though... (The Windows message q…
if(dataAvailable())
fetchData();
and assumed regular window messages to drive execution of this process. If you don't move the mouse or do anything else with the window, no messages are sent to it (unless a timer or something else does) and the message loop just waits for the next message, so that code doesn't get run. If you move the mouse around in the window a constant stream of WM_MOUSEMOVE will drive the loop. Polling really shouldn't be done in the main message loop; one way to fix this is to move to a completely event-driven system where dataAvailable() sends a message that causes the main loop to run fetchData().