RawInputs organization

[qWord]

it is an 32Bit application - after removing the displacement of 8 it should work (theoretically :-))

see the attachment: a msgbox should appear, when pressing 'j'

[zemtex]

Ok I will look into it, I thought it was the single raw read variant, Didnt pay too much attention. :bdg

[zemtex]

Why not use the main window as the target and fetch it in peekmessage? I read somewhere that using a dummy window is quite common. But why is it?

To be able to run the main loop undisturbed?

[qWord]

window-related message are only post to the thread that create the window - that the whole reason.
now, did the programm work?

[zemtex]

Yes works wonderfully

[zemtex]

The only thing I would add is RIDEV_NOLEGACY to the flags when creating rawinput to get rid of mouse and key legacy messages.
I would also avvoid allocating memory, the buffer doesnt go above 40 bytes for keyboard and mouse raw inputs, you can declare that
buffer. Even worse is to use globalalloc.

Other than that it looks good to me. I will copy your philosophy, but code my own code. I have my own codestyle so i'm sure you understand
that I need to code it myself. But like I said, I have studied the philosophy behind the code and will copy some of that.

:U

[qWord]

I would also avoid allocating memory, the buffer doesnt go above 40 bytes for keyboard and mouse raw inputs, you can declare that
buffer.

That's dangerous - what is if windows collect two or more events and send them to you in a bunch? (for this case the function is designed)

[zemtex]

If you use GetRawInputBuffer you should allocate using heap allocation (not globalalloc) but if you use GetRawInputData you should use a local declared buffer of 40 bytes.

Allocating memory takes time, you could also measure the peak usage of memory during runtime to find a good sized buffer and then preallocate it.

Memory allocation is not such a big deal (usually), but we're dealing with directinput coding here so it is relevant, allocating memory should be avvoided if possible, especially in a RawInput handler, we want things to happen FAST and get the hell out of there.

[zemtex]

If your buffer is too small, catch an error if the returned required size is above your buffer size, you can avvoid the danger that way.

[zemtex]

Also beware when you declare RIDEV_NOLEGACY your window will not be taking mouse clicks or keyboard clicks, it works best for fullscreen programs. But then again, games that use RawInput is usually a full program  :dazzled:

If you dont declare it you will recieve multiple unneccesary WM_KEYUP WM_KEYDOWN and such useless messages that you wont process anyway.

[zemtex]

According to windows api documentation if you create a secondary dummy window and it gets focus, the main window will be in the background moving from priority 9 down to 7 and the rawinput handler window gets priority 9. Perhaps we ought to setfocus to the main window after creating the dummy window?

I've peeked into "Message-Only-Windows", I was hoping this could be used in replacement of creating a dummy "button" window. But I have my doubts it can be used for that. Anyone check it out: http://msdn.microsoft.com/en-us/library/ms632599%28v=vs.85%29.aspx#message_only
It looks like it is specially designed for this purpose.

Do you think this special message processing window can be used as a rawinputbuffer handler? The docs says such a window cannot be enumerated.  :snooty:

You can set the main window back to top priority by using SetForegroundWindow function

Btw, i've been thinking. Instead of using an event in your handler, you could kill the event and just use PostThreadMessage. That will eliminate some complexity and reduce overhead.

[zemtex]

I measured amount of messages retrieved by using a 5700 dpi mouse at full resolution and moving it as fast as possible, I measured the event count per second.

It peaked at 507 events per second (When moving mouse as fast as possible) I didnt output anything while measuring, I set a tickcounter every 1000 ms and output the result to the window caption text.

I couldnt get any higher number on any other dpi settings either. Thats nothing a computer cant handle. Thats not even a single event per millisecond. I have underestimated computers  :bdg

[qWord]

zemtex,
the question is why to use raw input. - the normal message processing (WM_MOUSEMOVE,...) is really enough for mouse and keyboard input. Also, as I notice, there are bugs in the implementation at least on Win7-x64.

qWord

[zemtex]

The good part of using legacy messages is that you dont have to deal with low level coding and you get pointer ballistics integrated in a single package.