GetWindowLong, hEdit, GWL_WNDPROC

[qWord]

it's easy to use GCL_CBWNDEXTRA with SetClassLong to add 4 bytes to every window

According to the documentation this is not possible. Using a window property would be an easy alternative.

[Antariy]

Not sure what you mean, but this is typical thing to do. That's how RAM Clear's custom-drawn buttons work. It was limitation in extra windows' bytes in Win9x but even there there is space for ~10 such 4 byte pointers in the every window extra space.
Just make class changements before creating new windows of that class, like I said in the full text of the quoute.

[qWord]

yep, I probably misinterpreted the documentation for SetClassLong(GCL_CBWNDEXTRA,...):

Sets the size, in bytes, of the extra window memory associated with each window in the class. Setting this value does not change the number of extra bytes already allocated

The second sentence means that you can increase the value, but not decrease it  :redface:
Regardless that I prefer properties in situation where I did not registered the class: Set/GetProp().

qWord

[Antariy]

Set/GetProp is a good choice, too :t It even better than extra class data if there is no need to associate some own data with every window of some class.

[jj2007]

Before a window is destroyed (that is, before it returns from processing the WM_NCDESTROY message), an application must remove all entries it has added to the property list.

Will that happen automatically on ExitProcess?

[qWord]

Before a window is destroyed (that is, before it returns from processing the WM_NCDESTROY message), an application must remove all entries it has added to the property list.

Will that happen automatically on ExitProcess?

IIRC, they are implemented as global atoms, which are removed with the process. However, I wouldn't bet on that and simple remove them on destruction.

EDIT: corrected

[Antariy]

Before a window is destroyed (that is, before it returns from processing the WM_NCDESTROY message), an application must remove all entries it has added to the property list.

Will that happen automatically on ExitProcess?

Probably not. The point is: the string which "names" the data associated with a window is a global atom, therefore, if you register it - you should unregister it, otherwice it will not be removed from list of registered atoms untill system reboot. There are less than 65536 atoms available in the system, so, in some degree properties look like limited resource (considering that system running not only our application, but many others, and any of them can create a bunch of a properties etc etc - especially today's "heavy-GUI" applications). But it actually don't seem to have much influence on the system performance, probably that's due to small possible list "name-value" of atoms. And second atom registration with the same name will just return the previous atom value.

Edited: added a quote the post was answering to.

[qWord]

Seem they are nice window feature as long as handled correct  8). However, I find it a bit curios that the atoms are not automatically removed (on window destruction)¹, because it would be simple to implement that...

EDIT: [1] added

[dedndave]

maybe not - if they are shared between processes

[qWord]

maybe not - if they are shared between processes

There must be some kind of list for each window, which hold the atom identifiers. Going through that list and removing the global atoms (GlobalDeleteAtom) should be no problem IMO.

[jj2007]

Especially since FreeGlobalAtom uses a counter anyway. But it would require keeping a list of atoms used by the app so that at ExitProcess the OS knows what to release.

One problem is that MSDN uses this "you have to release" too often.
Yes, you have to release the DC if you use it in a loop (if not, ExitProcess will release the heap mem)
Yes, you have to release the brush if you use it in a loop
Yes, you have to release atoms - always
No, you don't have to remove the subclass on exit - ExitProcess will do it for you.

And M$ shies away from documenting that clearly. As a result, coders are uncertain and hide behind the argument "OMG, don't do that, it's not documented"  ;)

It's lousily documented, that's true

[dedndave]

i can't be too critical - lol
it's a big OS and, overall, they documented it fairly well
i was a Logistics Engineering Technical Writer, long ago (Sperry Flight Systems)
i can sympathize with how much effort goes into documenting something so big and complex

as for freeing stuff...
my theory is, if i DO it, i generally try to UNDO it before exit
it's just a good habit to get into, particularly with GDI stuff
expecting ExitProcess to clean something up is asking for a memory leak
it's not as though it causes pain to add an extra line of code - lol

[qWord]

But it would require keeping a list of atoms used by the app so that at ExitProcess the OS knows what to release.

yes, I agree. However, I was referring on destruction of a window, where is should be no problem to remove the added properties - this would not required any cleanup on process exit.

[Antariy]

There are obviously can be some points that they want to make things a bit more obscure than they are. First of it: they want to sell their stuff for developers. One may want to buy such thing like MSVC to use MFC/.NET and to make cute-GUI apps instead of studing a bunch of entangled, sometimes unclear, and - very frequently - not full documentation.
For such things like device drivers - it's even more profitable area, there are usually a "big guys" who can pay high costs for info and tools.
So, they obviously have been doing a big job documenting something, but not all and not totally. For an instance - it is better if you buy Microsoft's Press book about "undocumented" functions and methods like native API are, than if you'd know that all for nothing. The same for "Certified courses" of any speciality which has relation to the Windows and its tools. Support of the products etc. That's just profitable business: who has more information - has more power, so, sell the information - this will always bring a profit - that is how it works. Probably.

[jj2007]

expecting ExitProcess to clean something up is asking for a memory leak

If the memory is your own heap, no problem - it will be abandoned completely. That concerns 99% of all cases (alloc, brushes, all GDI stuff, ...).
The 1% are global atom tables. Not sure, though, if ExitProcess can handle COM & OLE:

"OleUninitialize calls the CoUninitialize function internally to shut down the OLE Component Object(COM) Library."