🎉 Celebrating 25 Years of GameDev.net! 🎉

Not many can claim 25 years on the Internet! Join us in celebrating this milestone. Learn more about our history, and thank you for being a part of our community!

RegisterClassEx

Started by
4 comments, last by matt77hias 4 years, 10 months ago

Are there disadvantages of registering a separate window class (using RegisterClassEx) for each window instead of reusing the same window class? And if so what are these disadvantages?

🧙

Advertisement

From MSDN

Quote

Each window class has an associated window procedure shared by all windows of the same class. The window procedure processes messages for all windows of that class and therefore controls their behavior and appearance

So this means if you share a class between two windows, they not just share the title (if I remember correctly), they also share the same messaging procedure. This may cause one window resize to also resize the other window and so on but it becomes tricky if you declare an override for the window message handling, especially if you intend to use HID API or UPnP features

2 hours ago, Shaarigan said:

So this means if you share a class between two windows, they not just share the title (if I remember correctly), 

Setting the window's title is done per instance of the window, regardless of whether they have the same class. That's why SetWindowText takes a HWND parameter

2 hours ago, Shaarigan said:

This may cause one window resize to also resize the other window and so on

The window procedure has the window instance as first parameter, so it is perfectly possible to distinguish window instances.

10 minutes ago, Koen said:

Setting the window's title is done per instance of the window, regardless of whether they have the same class

Ah right, I looked into my engine source. I got confused with the window class name


WNDCLASSEXA wc; Drough::memset(&wc, 0, sizeof(wc));
if(!boolean_cast(GetClassInfoExA(GetModuleHandleA(0), WIN32_SURFACE_CLASS_NAME, &wc)))
{
	wc.cbClsExtra = 0;
 	wc.cbWndExtra = 0;
 	wc.style = CS_OWNDC;
 	wc.cbSize = sizeof(WNDCLASSEX);
 	wc.hInstance = GetModuleHandleA(0);
 	wc.lpfnWndProc = WndProc;
 	wc.hCursor = LoadCursor(NULL, IDC_ARROW);
 	wc.hbrBackground = (HBRUSH)GetStockObject(BLACK_BRUSH);
 	wc.lpszClassName = WIN32_SURFACE_CLASS_NAME;
 	wc.lpszMenuName = 0;

 	if(!RegisterClassExA(&wc)) return 0;
 }
		
 handle = CreateWindowExA(WS_EX_APPWINDOW, WIN32_SURFACE_CLASS_NAME, 
 	name,
 	((border) ? (WS_OVERLAPPEDWINDOW ^ WS_THICKFRAME) : WS_POPUP),
 	0, 
 	0,
 	CW_USEDEFAULT,
 	CW_USEDEFAULT,
 	0,
 	0,
 	#if defined(PTR_SIZE) && PTR_SIZE == 64
 	(HINSTANCE)(uintptr_t)GetWindowLong((HWND) handle, GWLP_HINSTANCE),
 	#else
 	(HINSTANCE) GetWindowLong((HWND) handle, GWL_HINSTANCE),
 	#endif
0);

 

Using a single window procedure is not a problem for me as you can pack the this pointer upon registering a class, which can then be unpacked upon handling a message. So it is possible to go completely OO with this procedural programming style.

It is more an issue of doing the bookkeeping of reusing and deregistering window classes. If it does not have a real disadvantage, creating a window class per window is more elegant (less boilerplate).

🧙

This topic is closed to new replies.

Advertisement