2

I have a thread that captures the state of all input devices every x milliseconds. To do this, I am using GetAsyncKeyState() for all keys, GetCursorPos() for mouse x/y, and XInputGetState() for controller state. What this doesn't report is the mouse's scroll wheel, which isn't expressed in a single value but a change in value, which means it must be determined through a window message (WM_MOUSEWHEEL).

Is it safe to call PeekMessage() from this thread (which is not my message pump thread), provided I use my own synchronization?

NmdMystery
  • 2,778
  • 3
  • 32
  • 60
  • 3
    It might be safe in terms of only one thread calling the function at a time, but might not give the result you expect, or even work at all. Only the tread creating the window should handle the messages. See e.g. [this old answer](http://stackoverflow.com/a/1964117/440558). – Some programmer dude Jul 25 '14 at 21:55
  • @JoachimPileborg I guess the solution is to use the mousewheel for gui only, and handle any gui state on the message pump / rendering thread. If you want to post this as an answer, I'll upvote and accept it. – NmdMystery Jul 25 '14 at 23:00
  • Each thread has its own message queue, and `PeekMessage` only looks in the queue of the calling thread. So yes, it's thread-safe, but it won't do you any good as `WM_MOUSEWHEEL` is likely not sent to your worker thread, and won't be found in its message queue. `WM_MOUSEWHEEL` goes to the thread that created the window currently having focus. – Igor Tandetnik Jul 26 '14 at 00:10
  • Side note: If you are using [`GetAsyncKeyState`](http://msdn.microsoft.com/en-us/library/windows/desktop/ms646293.aspx) be sure to read the remarks section in the docs. Basically, the pressed since previous call flag is a global state provided only for compatibility and if another application (or another instance of your program) calls it you might miss some key presses. – user2802841 Jul 26 '14 at 01:28

0 Answers0