   WM_INPUT Library
  I heard that Direct Input just wraps the WM_INPUT messages, and I have worked with WM_INPUT before and know how to get it working, but what I don't know is how to put it into a separate library and get it to work. I know that WM_INPUT is embedded into an application's message loop, so how can I put the WM_INPUT handling code in a library, and have it so the library only needs to know an app's hWnd or hInstance like Direct Input? BTW, I know I could just use Direct Input, but I want to learn how Direct Input works under the hood, so don't say "Don't bother trying and just use Direct Input already."   
  You should be able to accomplish what you're after using window subclassing. It's a pretty straightforward procedure but you'll need to be careful as there are a few nasty pitfalls that might crop up, especially if multiple pieces of code try to subclass the same window simultaneously.   ;Quote:Original post by xXShadowAsasNXxdon't say "Don't bother trying and just use Direct Input already."I was going to say the opposite.   ;  Well, the way DirectInput does it is it creates a dedicated thread and uses a separate, hidden window. Then that thread's message pump is what processes the WM_INPUT messages.This is why people recommend you don't use DirectInput - creating a whole separate window and thread just for input is silly. If you want to create your own libarary, the way I would do it is I would require that the application forward the WM_INPUT message (and parameters) to the library - it's only one extra call that you need to make, and it saves you having to go through all the trouble that DirectInput goes through.Now, DirectInput didn't always work like that. Before raw input was common (i.e. before Windows XP) it used some other mechanism, and it actually provided some value. The problem for the developers of DirectInput was that even once raw input became available, they couldn't change the interface to the API otherwise so many applications that already used it would break. But since you're starting from scratch, you don't have that restriction.   ;  You can do a message query in the library, limited to your HWND and limited to RAWINPUT messages only.MSG msg = {0};while ( ::PeekMessage( &msg, myHWND, WM_INPUT_DEVICE_CHANGE, WM_INPUT, PM_REMOVE | PM_QS_INPUT ) ){ // process msg... }This can basically be called from anywhere in the code. The catch is that it must be called before you call the main MSG proc cuz then DefWindowProc will eat the unhandled WM_INPUT messages. That means threading it would be tricky, or you need to do your main message proc in a way that it processes every message except the two RAWINPUT ones. ( filter to 0, (WM_INPUT_DEVICE_CHANGE-1) and (WM_INPUT+1), UINT_MAX maybe? ) This works for me, although I am not calling it from an external library. I have no idea how costly is filtering the messages like this.   ;Quote:Original post by darkelf2k5The catch is that it must be called before you call the main MSG proc cuz then DefWindowProc will eat the unhandled WM_INPUT messages. That means threading it would be tricky, or you need to do your main message proc in a way that it processes every message except the two RAWINPUT ones. ( filter to 0, (WM_INPUT_DEVICE_CHANGE-1) and (WM_INPUT+1), UINT_MAX maybe? )This works for me, although I am not calling it from an external library. I have no idea how costly is filtering the messages like this.You would need to do the filtering regardless of whether you were doing multi-threading. The problem is that message delivery is completely asynchronous. So if your library did it's (filtered) PeekMessage, but a WM_INPUT arrived before your main loop's PeekMessage, then the WM_INPUT would go to your main loop and you'd lose it if you didn't do the filtering you mentioned.I think the simplest solution is to simply forward WM_INPUT messages from your main loop to your library.   ;  Thanks for all of the responses guys. I have decided I will just require the user put a function in their message loop to forward the messages to the library.   