Back to General and Gameplay Programming

[Win32] Message Handling without Global Wnd Proc

General and Gameplay Programming Programming

Started by RealMarkP July 23, 2009 10:05 AM

14 comments, last by Aardvajk 14 years, 9 months ago

RealMarkP

216

Author

July 23, 2009 10:05 AM

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)?

------------Anything prior to 9am should be illegal.

Vortez

2,714

July 23, 2009 10:09 AM

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...

My Projects

Erik Rufelt

5,903

July 23, 2009 10:12 AM

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.

RealMarkP

216

Author

July 23, 2009 10:22 AM

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.

------------Anything prior to 9am should be illegal.

rip-off

11,000

July 23, 2009 10:25 AM

Why do you want to do this?

blog | twitter

RealMarkP

216

Author

July 23, 2009 10:28 AM

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.

------------Anything prior to 9am should be illegal.

SiCrane

11,840

July 23, 2009 10:29 AM

You don't need a dummy function to set the WndProc to DefWindowProc(). DefWindowProc() can be used directly as a window procedure.

Evil Steve

2,021

July 23, 2009 10:30 AM

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...

RealMarkP

216

Author

July 23, 2009 10:34 AM

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.

------------Anything prior to 9am should be illegal.

Evil Steve

2,021

July 23, 2009 10:45 AM

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.

[Win32] Message Handling without Global Wnd Proc

This topic is closed to new replies.

Popular Topics

Recommended Tutorials

[Win32] Message Handling without Global Wnd Proc

This topic is closed to new replies.

Popular Topics

Recommended Tutorials

Reticulating splines