Jump to content
  • Advertisement
Sign in to follow this  
RealMarkP

[Win32] Message Handling without Global Wnd Proc

This topic is 3280 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

If you intended to correct an error in the post then please contact us.

Recommended Posts

Is it possible to handle messages without having to DispatchMessage() them to a global function?
	WNDCLASSEX tWndClass;

	// Register class
	tWndClass.cbSize		= sizeof(WNDCLASSEX);
	tWndClass.style			= CS_HREDRAW | CS_VREDRAW;
	tWndClass.lpfnWndProc	= NULL; // Do not specify a global function to call
	tWndClass.cbClsExtra	= 0;
	tWndClass.cbWndExtra	= sizeof(Void *);
	tWndClass.hInstance		= NULL;
	tWndClass.hIcon			= NULL;
	tWndClass.hIconSm		= NULL;
	tWndClass.hCursor		= LoadCursor(NULL, IDC_ARROW);
	tWndClass.hbrBackground	= NULL;
	tWndClass.lpszMenuName	= NULL;
	tWndClass.lpszClassName	= sWindowName.toCharString();
	RegisterClassEx(&m_oWndClass);


	MSG uMsg;

	// Loop through until all messages are processed
	while (PeekMessage(&uMsg, NULL, NULL, NULL, PM_REMOVE))
	{
		// Dispatch the Message to the Message Proc
		TranslateMessage(&uMsg);
		//DispatchMessage(&uMsg); // Skip this step and instead handle messages here

		// Do message handling here
	}


I know this is not how MS wants us to code this, but is it feasable? Would all events be caught (Keyboard, sizing, mouse, windowing, etc)?

Share this post


Link to post
Share on other sites
Advertisement
Why would you want to do that in the first place?? If you don't wanna program in windows, make a console app?? Otherwise i dont see the point of doing that...

Share this post


Link to post
Share on other sites
Not really. You can do it in your loop, like the following:

DefWindowProc(msg.hwnd, msg.message, msg.wParam, msg.lParam);


You still need a WndProc function to create a window though, since it is called from within CreateWindowEx, before the function even returns, with a WM_CREATE message for example.

Share this post


Link to post
Share on other sites
Quote:
Original post by Erik Rufelt
Not really. You can do it in your loop, like the following:

DefWindowProc(msg.hwnd, msg.message, msg.wParam, msg.lParam);


You still need a WndProc function to create a window though, since it is called from within CreateWindowEx, before the function even returns, with a WM_CREATE message for example.


So, if I create a dummy global function that just returns a DefWindowProc() call, it would catch the WM_CREATE, etc messages. I'm not too worried about not catching WM_CREATE messages.

Share this post


Link to post
Share on other sites
Quote:
Original post by rip-off
Why do you want to do this?


It's more of an experiment. I'm trying to segregate the windowing functionality from the Message handling functionality.

Share this post


Link to post
Share on other sites
You don't need a dummy function to set the WndProc to DefWindowProc(). DefWindowProc() can be used directly as a window procedure.

Share this post


Link to post
Share on other sites
Quote:
Original post by RealMarkP
So, if I create a dummy global function that just returns a DefWindowProc() call, it would catch the WM_CREATE, etc messages. I'm not too worried about not catching WM_CREATE messages.
You could, but you can't do any message processing in your main message loop.
For instance, WM_SIZING is sent to your window when it's being resized. Calling DefWindowProc says "Ok, I'm happy with that size", and you can change the size before calling it. It's not valid to modify the sizing rect outside of the window proc.

Also, there are functions like TranslateMessage which emit messages to your window proc - without a window proc you'll never get WM_CHAR messages and probably a bunch more.
You may not be "too worried about not catching WM_CREATE messages" just now, but if you ever need to create child windows (Such as buttons or toolbars), you'll need to - and it's not possible without a window proc.

This topic has come up a fee times, and every time the answer is "Don't do it". Even if it happens to work just now, it's the sort of thing that'll just break horribly on other PCs, if there's any software on the PC that hooks any window messages, if it's a different windows version, different service pack, or different anything, or if you try to handle a new message type. It's really not worth the hassle.

Why do you want to do away with your window proc? If it's for encapsulation, it's normal to wrap your window proc up in a class to make it all nice and OOPy...

Share this post


Link to post
Share on other sites
Quote:
Original post by Evil Steve
Quote:
Original post by RealMarkP
So, if I create a dummy global function that just returns a DefWindowProc() call, it would catch the WM_CREATE, etc messages. I'm not too worried about not catching WM_CREATE messages.
You could, but you can't do any message processing in your main message loop.
For instance, WM_SIZING is sent to your window when it's being resized. Calling DefWindowProc says "Ok, I'm happy with that size", and you can change the size before calling it. It's not valid to modify the sizing rect outside of the window proc.

Also, there are functions like TranslateMessage which emit messages to your window proc - without a window proc you'll never get WM_CHAR messages and probably a bunch more.
You may not be "too worried about not catching WM_CREATE messages" just now, but if you ever need to create child windows (Such as buttons or toolbars), you'll need to - and it's not possible without a window proc.

This topic has come up a fee times, and every time the answer is "Don't do it". Even if it happens to work just now, it's the sort of thing that'll just break horribly on other PCs, if there's any software on the PC that hooks any window messages, if it's a different windows version, different service pack, or different anything, or if you try to handle a new message type. It's really not worth the hassle.

Why do you want to do away with your window proc? If it's for encapsulation, it's normal to wrap your window proc up in a class to make it all nice and OOPy...


Just curious, the above mentioned events would be sent into the WndProc function via DispatchMessage(), no? I only read of a few functions (such as WM_CREATE) that get directly injected into the WndProc function without going through the usual GetMessage/TranslateMessage/DispatchMessage loop.

Share this post


Link to post
Share on other sites
Quote:
Original post by RealMarkP
Just curious, the above mentioned events would be sent into the WndProc function via DispatchMessage(), no? I only read of a few functions (such as WM_CREATE) that get directly injected into the WndProc function without going through the usual GetMessage/TranslateMessage/DispatchMessage loop.
Actually, looking into this more, I'm wrong - TranslateMessage() causes messages to be posted to the application's message queue, not sent direct to the window proc. However, I'd still be extremely cautious about messages that may be sent to the window proc directly; and there may be some added in a future version of Windows.

Share this post


Link to post
Share on other sites
Sign in to follow this  

  • Advertisement
×

Important Information

By using GameDev.net, you agree to our community Guidelines, Terms of Use, and Privacy Policy.

We are the game development community.

Whether you are an indie, hobbyist, AAA developer, or just trying to learn, GameDev.net is the place for you to learn, share, and connect with the games industry. Learn more About Us or sign up!

Sign me up!