4 ms·
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 eve
by to3m 13y ago
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 queue is actually fairly straightforward, and if you read the documentation then it's simpler still. The somewhat magical WM_PAINT message is a bit ugly, but aside from that it's actually quite difficult to get things massively wrong. Which is probably why this sort of freakish bug is rather rare.)
- lisper 13y agoThat sounds like a very plausible theory.
- userbinator 13y agoAs someone who has worked with Win32 for a long time, I think the problem is quite simple; in the message loop body someone put something like 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().