Window class properties apply to all windows that belong to the class

Date:	June 15, 2006 / year-entry #200
Tags:	code
Orig Link:	https://blogs.msdn.microsoft.com/oldnewthing/20060615-00/?p=30863
Comments:	6
Summary:	Window class properties apply to all windows that belong to the class. That's why they're called class properties. This seems like an obvious thing to say when put in so many words, but I see many "solutions" that lose sight of this simple fact. All the properties that you set in the WNDCLASS (or WNDCLASSEX)...

Window class properties apply to all windows that belong to the class. That's why they're called class properties. This seems like an obvious thing to say when put in so many words, but I see many "solutions" that lose sight of this simple fact.

All the properties that you set in the WNDCLASS (or WNDCLASSEX) are window class properties, as are the properties that you can access via Get/SetClassWord/Long/LongPtr. This means that when you change those properties, they affect the entire class. For example, if you write

SetClassLongPtr(hwnd, GCLP_HCURSOR, (LONG_PTR)hcurNew);

then you aren't just changing the cursor for the window specified by hwnd. You're changing the cursor for all windows of the same class as hwnd. For example, if hwnd is an edit control, then you changed the default cursor for all edit controls.

But what if you want to change a class property for just one particular window instead of for all windows of a class?

If you want to change the menu, background, cursor, or icon for a particular window, you can override the class default on a per-window basis:

Property	Method
Menu	`SetMenu(hwnd, hmenuNew)` + destroy the old menu
Background	Override `WM_ERASEBKGND`
Cursor	Override `WM_SETCURSOR`
Icon	`SendMessage(hwnd, WM_SETICON, iconSize, (LPARAM)hiconNew)`

Comments (6)

Yaron says:

June 15, 2006 at 11:11 am

What about subclassing each individual window/control with a simple implementation that otherwise just passes everything to the previous class’ window procedure?

[What about it? If that’s all it did, it seems like an awfully expensive nop. -Raymond]
Ring Zero says:

June 15, 2006 at 6:54 pm

It would probably have been wiser for functions like SetClassLongPtr to take a WNDCLASS or an ATOM instead of an HWND. It makes more sense, and I bet nobody would’ve made the mistake of thinking the new value only applied to the one window.
Norman Diamond says:

June 15, 2006 at 9:13 pm

Menu

>SetMenu(hwnd, hmenuNew) + destroy the old menu

It always makes me nervous, trying to figure out if an old menu (or font or whatever) should be destroyed. If the old object belonged to a window class, and we destroy the old object, how do we know that other windows of the same class aren’t going to get in trouble?
steveg says:

June 15, 2006 at 9:52 pm

I always liked the Set[Class|Window].* functions — so obviously additional memory allocated at the end of a C struct (at least to my way of thinking, could’ve been assembler originally). And definitely an interface designed by and for people of, dare I say, a bygone age.

The other thing of note, is the lack of orthogonality in the ways the class defaults are overridden.

I’m not saying these are bad, they’re simply not something anyone would design in 2006. Right?
Yaron says:

June 18, 2006 at 5:28 am

> What about it? If that’s all it did, it seems

> like an awfully expensive nop.

I think what I was trying to ask is *how much* really expensive is
the overhead? Especially compared with the relative simplicity of then
being able to use those class functions to change a parameter when
needed, and, erm, let the OS worry about it?

I agree it’s messier at runtime, but if some app requires multiple
windows/controls like that, writing a single MakeNewClass function and
a generic minimal window procedure for it can look more appealing then
overriding specific messages per-control in several different window
procedure of the application.

BTW, off-topic, but your in-comment replies do not show up in
comment feeds. You may want to raise a request to have a comment
updated in the feeds when it’s edited. It’s a very safe assumption that
your replies are important to everyone monitoring a post here, so when
you do reply people shouldn’t see that there are no new comments on the
post…

[If you want to register one generic class and subclass it every time you create it, then you can do that. You can work out the overhead yourself (a few extra calls at window creation, plus a few more at every window message) – you get to decide if it’s worth it. Note of course that if you do this then anybody who tries to manipulate your program via FindWindow (e.g. your automated testing system) will be in for a surprise. If you want to request features for the blog software, you can raise them to the software vendor. -Raymond]
testing123 says:

June 20, 2006 at 10:53 am

Is automated testing systems incompatible with subclassed windows?

Comments are closed.

*DISCLAIMER: I DO NOT OWN THIS CONTENT. If you are the owner and would like it removed, please contact me. The content herein is an archived reproduction of entries from Raymond Chen's "Old New Thing" Blog (most recent link is here). It may have slight formatting modifications for consistency and to improve readability.

WHY DID I DUPLICATE THIS CONTENT HERE? Let me first say this site has never had anything to sell and has never shown ads of any kind. I have nothing monetarily to gain by duplicating content here. Because I had made my own local copy of this content throughout the years, for ease of using tools like grep, I decided to put it online after I discovered some of the original content previously and publicly available, had disappeared approximately early to mid 2019. At the same time, I present the content in an easily accessible theme-agnostic way.

The information provided by Raymond's blog is, for all practical purposes, more authoritative on Windows Development than Microsoft's own MSDN documentation and should be considered supplemental reading to that documentation. The wealth of missing details provided by this blog that Microsoft could not or did not document about Windows over the years is vital enough, many would agree an online "backup" of these details is a necessary endeavor. Specifics include:

A "redesign" after 2019 erased thousands of user's comments from previous years. As many have stated, the comments are nearly as important as the postings themselves. The archived copies of the postings contained here retain the original comments.
The blog has changed domains many times and the urls have otherwise been under constant change since 2003. Even when proper redirection has been set up for those links, redirection only works for a limited period of time. For example, all of the internal blog links that were valid in early 2019, were broken by 2020 without proper redirection.
The blog has been under constant re-design and re-theming since its inception. It is downright irritating to deal with a bogged-down site experience as the result of the latest visual themes designed for cell-phone browsers. As of this writing, it is cumbersome to navigate titles with only 10 entries per page. While it is nice that the official site has a search feature, searching using this index (with all titles on a single page) is much quicker (CTRL-F in most browsers).

<-- Back to Old New Thing Archive Index