Print

Please login or register.
1 Hour 1 Day 1 Week 1 Month Forever
Login with username, password and session length

[pjcast]

I came across a project on Ogre forum which had source available, and used Window's hooks to specifically capture (and being unobtrusive of client app) Window's Messages. Specifically, using something like: SetWindowsHookEx(WH_GETMESSAGE, GetMessageProc, hInstance, GetCurrentThreadId())

I'm not quite sure best way to design the new Keyboard/Mice type classes yet. Just putting this info out there in case any brave person wanted to write some new handlers based on this. But, would probably simply buffer the received events until the user called capture (so events would come in on the thread that the user calls capture on). But, the benefits of using window's messages would probably be:
* Mouse: possible to support multiple Mice
* Mouse: the speed/sensitivity/etc would be affected by the User's System settings - maybe good/maybe bad
* Keyboard: Possible improved Locale Handling
* Keyboard: Support for all features of keyboard that perhaps DirectInput doesn't expose
* Keyboard & Mouse: Would no longer need to pass in top-level window handle, so could work with Child Windows easily.

So, there are some gains. There may, however, also be some pitfalls. But, no way of knowing until doing such a task. Though, I don't have any ETA when I would be able to start/complete such a task. Just putting this out there

[OvermindDL1]

Those are the exact methods I was talking about earlier, and yes it adds lots of niceities, however Windows is screwed... er... I mean that most hook types require Admin profile access to use.  It would be best to support it, but have DI for a fallback and still for joystick type inputs.  Since the hooks are called in the kernal context would probably be best to buffer using an atomic circular queue, that is what I do.

If you set hooks on the keyboard and mouse themselves (which is what I actually do) then you get the detailed info, before any weird windows transformations (so you would not get profile modifications on mouse movement speeds for example), and it is faster in execution.

[pjcast]

If you set hooks on the keyboard and mouse themselves (which is what I actually do) then you get the detailed info, before any weird windows transformations (so you would not get profile modifications on mouse movement speeds for example), and it is faster in execution.

I'm not sure I get what you mean by setting the hooks on the Mouse/Keyboard itself? You are saying use on of the hook filters which specifies input messages only?

As for supporting DirectInput, yes it would be necessary for joystick handling (since I don't really want to switch that to Windows MM System). Though, from what you are saying, the hooks would not always work? In which case I would need to still use DirectInput... hmm, makes the switch not really seem worth it in that case.