[SOLVED] Reading the mouse wheel delta in a side thread

[furious programming]

I have a side thread that gets the state of the gamepad, keyboard and mouse buttons 60 times per second (just like a regular game). To read the state of controller buttons I use the joyGetPosEx function, for keyboard and mouse buttons I use the GetKeyState function. The problem occurs with the wheel of the mouse, because the status of the wheel cannot be read with GetKeyState.

After the wheel is turned, the system sends a message to the window, this is processed in a loop, and the OnMouseWheel event is dispatched. The problem, however, is that the state of the mouse buttons is to be retrieved in a side thread (the form should have nothing to do with it), and the thread will not get this message about the rotation of the scroll.

I can just use the OnMouseWheel event to write/increment the delta in the custom form field, and the thread will read that value and reset the variable. But this is a fallback option because I don't like it — sounds dirty.

Anyone know of any way to read the mouse wheel delta without using a form message loop? Is it even possible?

[440bx]

Anyone know of any way to read the mouse wheel delta without using a form message loop? Is it even possible?

I don't believe it is possible because scroll wheel actions are not a state (like a key being pressed).  The scrolling of the wheel is _always_ in a message.

[furious programming]

Ok, thank you for the explanetion. What do you think about mouse hook?

[440bx]

Ok, thank you for the explanetion. What do you think about mouse hook?

You're welcome.  As far as a mouse hook, it seems to me that, whatever the hook routine does could just as well be done when processing the WM_MOUSEWHEEL message.  IOW, I don't see what advantage, if any, hooking the mouse would provide.

At this time, I think the "dirty" solution (or a variation thereof) you mentioned originally may very well be the simplest.  One mechanism that comes to mind would be to have the thread that pumps window messages forward the message to the thread that keeps track of the other various events.  That would require that thread to have a message queue and use either GetInputState or PeekMessage to find out if it got one of those mouse wheel messages without blocking for it.  That's the closest (and simplest at this time) thing that comes to mind to implement a "mouse wheel state" for the "state" thread.

HTH.

[furious programming]

Ok, everything is clear. Probably I will do it in a ”dirty” way—declare a global variable for scroll state (forward, middle and backward) in the from of enum and read it's value directly from the side event, without synchronization (it will be not needed). There is no sense to do a complicated code.

Thank you again, problem is solved.