PeekMessage and CALLBACK messages....
Author
Does anyone know how to get the WM_MOVE/WM_MOVING message with either GetMessage or PeekMessage?
I tried putting this in my Window Process but it doesn't work like it did for WM_KILLFOCUS.
case WM_MOVE:
PostMessage(NULL, Msg, wParam, lParam);
break;
Same goes for WM_SIZE/SIZING. I need them to be able to be recieved within WinMain or I'll have to use global variables which I wish to stay away from.
Thanks.
Not sure, but have you tried just getting the message from Get/PeekMessage? ie..
MSG msg;if (PeekMessage (&msg, hWnd, 0,0,PM_REMOVE)) { // Catch message before call to wnd proc if (msg.message==WM_MOVE) PostMessage (NULL, Msg, msg.wParam, msg.lParam); TranslateMessage (&msg); DispatchMessage (&msg);}
Author
Yep, I've tried, it seems that those messages are never put into the queue, but rather are sent directly to the callback function of the window. Even when I PostMessage it happens which makes no sense given I've gotten around it with WM_KILLFOCUS and WM_ACTIVATE. I'm not sure why MOVE/SIZE doesn't work that way too.
You might try the PreTranslateMessage function. You can use it to "intercept" messages before they get translated and dispatched.
Best of luck!
-jouley
Best of luck!
-jouley
Author
Hmm, I might be understanding it wrong but the problem with that is not only are messages not being put into any sort of thread queue (going straight to the callback instead), but my application isn't MFC either.
Basically my callback is:
And then in my WinMain I have my PeekMessage loop:
The current status of my CALLBACK was my attempt at fixing it because that's how I fixed WM_KILLFOCUS. No matter what though, WM_MOVE is never seen by PeekMessage.
Basically my callback is:
LRESULT CALLBACK WndProcess(HWND hWnd, UINT Msg, WPARAM wParam, LPARAM lParam){ switch(Msg) { case WM_DESTROY: PostQuitMessage(0); return 0; case WM_KILLFOCUS: PostMessage(NULL, Msg, wParam, lParam); break; case WM_MOVE: PostMessage(NULL, Msg, wParam, lParam); break; } return DefWindowProc(hWnd, Msg, wParam, lParam);}And then in my WinMain I have my PeekMessage loop:
while(PeekMessage(&Msg,NULL,0,0,PM_REMOVE)) { switch(Msg.message) {... case WM_MOVE: Other.Update(); break;...The current status of my CALLBACK was my attempt at fixing it because that's how I fixed WM_KILLFOCUS. No matter what though, WM_MOVE is never seen by PeekMessage.
As you found WM_MOVE and similar messages (quite a lot actually) are not directly seen by the PeekMessage loop. They are sent directly (the window moving is done during a WM_NCLBUTTONDOWN message in a seperate Windows internal message loop).
Now since this is a seperate loop you won't see posted messages until the window move is finished. And SendMessage will bypass the queue.
In short: You won't be able to do that without ugly trickery. And you're not supposed to. You ought to process messages in the callback function. Period.
What are you trying to achieve?
Now since this is a seperate loop you won't see posted messages until the window move is finished. And SendMessage will bypass the queue.
In short: You won't be able to do that without ugly trickery. And you're not supposed to. You ought to process messages in the callback function. Period.
What are you trying to achieve?
Author
Basically I have an application that initializes the "engine" object in WinMain, and all the data is processed/rendered/updated inside this engine. So I have my WinMain process messages which are sent to this engine. If I were to use the callback to update the engine I would have to have a global so the object can be seen by both WinMain and the callback, but I want a global-less application.
Hmm, the problem persists however.
You can make a window wrapper class inside your engine which encapsulates the window proc. For this to work however you need to make that method static. Use the windows user value to pass a pointer to your class and pass on messages it.
There's a nice wrapper sample by the almighty Oluseyi: Clicky
Basically you will enter a world of pain if you try to process all messages inside WinMain for no benefit.
Try to incorporate the WindowProc inside your engine or abstract it away; however do handle the messages inside a proper callback proc.
You can make a window wrapper class inside your engine which encapsulates the window proc. For this to work however you need to make that method static. Use the windows user value to pass a pointer to your class and pass on messages it.
There's a nice wrapper sample by the almighty Oluseyi: Clicky
Basically you will enter a world of pain if you try to process all messages inside WinMain for no benefit.
Try to incorporate the WindowProc inside your engine or abstract it away; however do handle the messages inside a proper callback proc.
Author
Interesting, that link you provided is a way to go about it I've never seen, I'll have to give it a try. Thanks for the help. What is your preferred way to handle it?
Author
I appear to have run into a problem with that solution. This is a good day indeed.
It's all fine and functional, but the problem is that I don't want my messages handled in my Window class, but rather in my Engine class. So I've put the callback into the engine class, but my problem now is how to get it to communicate with that class since there's no 'This' in the callback. That tutorial shows how to do it via getting a handle to the window object, but what if I want to send my messages to my engine class? Any ideas?
It's all fine and functional, but the problem is that I don't want my messages handled in my Window class, but rather in my Engine class. So I've put the callback into the engine class, but my problem now is how to get it to communicate with that class since there's no 'This' in the callback. That tutorial shows how to do it via getting a handle to the window object, but what if I want to send my messages to my engine class? Any ideas?
This topic is closed to new replies.
Advertisement
Popular Topics
Advertisement
