Peekmessage (API) instead of Subclassing

[baka]

so, I wonder why most of the time when you ask about, how to use the mouse wheel you get the answer "you need subclassing or a 3rd dll".
but why not just use peekmessage?

right now I use peekmessage instead of, well, all the mouse up/down/move/keypressing/paint and plus I also get a free "doevents".

so, PeekMessage and the message information from it uMsg.
and uMsg we can retrieve:
for the mouse: WM_MOUSEMOVE, WM_LBUTTONDOWN, WM_LBUTTONUP, WM_LBUTTONDBLCLK, WM_RBUTTONDOWN, WM_RBUTTONUP, WM_RBUTTONDBLCLK, WM_MBUTTONDOWN, WM_MBUTTONUP, WMBUTTONDBLCLK, WM_MOUSELAST, WM_MOUSEWHEEL

for the keys: WM_KEYDOWN, WM_KEYUP, WM_SYSKEYDOWN, WM_SYSKEYUP

for paint: WM_PAINT (that I use to know if theres any changed in the system, like the user changed the resolution or the monitor hertz)

all this without the need of any subclassing and potential crashes.

how to use it?

Do While PeekMessage(uMsg, 0&, 0&, 0&, PM_REMOVE)
' here you look at uMsg ' 
TranslateMessage uMsg                         
DispatchMessage uMsg                           
Loop

example

if uMsg.Message = WM_MOUSEWHEEL then
   if uMsg.wParam > 0 Then Call WheelUP Else Call WheelDown
end if

so, this is not a "I need help", but more about a discussion or information if someone is interested in it.
I use this in a game-loop, so I call it 60 times a second (as it follows the monitor sync) and it works really well, no delays or lost input.

and...
if you have any more useful information how we can use PeekMessage/TranslateMessage/DispatchMessage, please write something.

(you need the values? check here: https://wiki.winehq.org/List_Of_Windows_Messages)

[wqweto]

if you have any more useful information how we can use PeekMessage/TranslateMessage/DispatchMessage, please write something.

When you use a custom message loop instead of the runtime provided one Form's navigation with keyboard becomes shaky and control's Validate event does not fire.

Using custom message loop with sparse DoEvents on WM_KEYFIRST to WM_KEYLAST messages might solve the issue.

cheers,
</wqw>

[Niya]

Do While PeekMessage(uMsg, 0&, 0&, 0&, PM_REMOVE)
' here you look at uMsg ' 
TranslateMessage uMsg                         
DispatchMessage uMsg                           
Loop

To be honest, I really don't like the idea of this message loop at all. It assumes that the VB6's runtime's own message loop isn't doing anything important before dispatching messages. The above code would deny the runtime from potentially doing important stuff before dispatching the message. This has the potential to cause problems. It would have been nice to see what the runtime's message loop actually does in between GetMessage and Translate/Dispatch.

If I were doing something like this, I would have probably created my own windows using CreateWindow, that way I know everything that is going on internally. Of course that introduces problems of it's own, mainly that it's extremely tedious to write GUI code the Win32 way.

However, all that aside. There might be situations where writing your own message loop like that in a VB6 GUI application would be safe. That would be a trial and error kind of thing though. Without the actual code for the runtime's message loop, we could only speculate on what it actually does.

[Niya]

One question though....why PeekMessage and not GetMessage?

[baka]

the Peekmessage loop is already discussed before a couple of times in the forum as an alternative to DoEvents.
GetMessage is looking for a specific "message", and while doing so will wait until it finds it. so you could say Peekmessage is looking at whatever its on the queue.

so "peek" on the queue is what Im doing. and based on the finding I do stuff.
for my "game loop" I can easily change "press/click" speed for any key/mouse click, if I want some restriction how often you can press.
that can be used in a word-editor to allow different typing speeds.

also, as I making a game and I need a loop to render the graphics, I also need doevents, and this will do fine.

of course, with everything, if you are making bad code it can mess things. my game is over 1MB in size running at top speed without any issues.
if this peekmessage was bad I would have found it by now.

and what about subclassing you think its more safe that using peekmessage?
also you can decide to "not" remove anything in the queue. theres option for that as well if you just want to peek without doing any "doevents" stuff.

[Niya]

and what about subclassing you think its more safe that using peekmessage?

Oh yes. It's much safer.

But a game engine errrr...I mean games engines might be different though. Usually when writing a game engine, the engine tends to end up being the program itself instead of something your program just calls. In this scenario a Form is basically just a rendering background and you won't be using things like controls and stuff so I guess you can get away with this PeekMessage loop you're using. But I'd be skeptical to use this in a typical GUI application with lots of controls, Forms and complicated event handling code.

However, if it works perfectly for you regardless of the kind of application you're writing, I see no problem using PeekMessage instead of subclassing. Remember, my skepticism about this depends entirely on what the VB6 runtime's own message loop may be doing before it dispatches a message. It could very well not being doing anything important. Thing is, we just don't know. There isn't a way to see the VB6 runtime's source code. VB6 was made before Microsoft was all gung-ho about open source.

[baka]

I have been using peekmessage "and" vbs own runtime message loop for years together.
it seems the peekmessage is doing "nothing". actually what peekmessage do is:

a "closed" loop, if you are not adding "doevents" it will freeze the application. this is basic knowledge right?
but if you add doevents, you are in control of the form, the mouse, the refresh-calls etc.
replacing doevents with this "peekmessage" is doing exactly that. the "closed" loop "exits" and gives the form "air".

so, the peekmessage itself, is just waiting that the hwnd has responded. so I move the mouse 10 pixel to the left. and when thats done the peekmessage contines.

theres no "I eat your input and leave you with an empty plate" scenario.
its more "I check if your input are executed and then I continue" scenario.

[Niya]

Yes, your PeekMessage loop is in effect what DoEvents does. But what I'm saying is, the actual DoEvents function and the runtime's message loop could very well be doing other "book keeping" stuff besides TranslateMessage/DispatchMessage to facilitate VB6's GUI engine. We just can't be sure of this. This could be what causes the problems wqweto describes in post #2. That's a clue that there may be some extra things that have to be done in a VB6 message loop for it's GUI engine to work correctly.

But I think I get what you're doing. It seems you're using PeekMessage as a replacement for DoEvents so you can do some extra processing on messages and any message you're not interested in you just pass to the normal runtime message loop. Is that correct? If that's the case, then everything should work correctly because the runtime's message loop is still involved which means it could do whatever important tasks need to be done for the VB6 GUI to work.

[baka]

sort of. Im actually not replacing the messages.
if the message says "mouse move", I grab the .x/.y and call the functions that uses that,
but Im not changing the message at all, the mouse move message is still there and will arrive to the destination.
we could say Im just looking at the messages, without touching it.
yes I could change the message content, like we do when we subclass. if we want to "stop the right mouse button" or a key to arrive,
but I don't see any reason doing that.

[Niya]

In that case, what you're doing should be safe. The most important thing is that the VB6's runtime's own message loop gets to process the message in the end.