RE: Custom icons per window class/name patch

["Ralf Habacker" <Ralf dot Habacker at freenet dot de>]

Erle wrote:
> I just did some runs with the commercial apps I use at work, and can
> see that many do *not* create custom classes or window_roles for each
> type of window.

KDE and gnome apps does.

> I think the best thing to do for the class naming is
> to just use an incrementing number and make each window its own
> class.

This was my first attempt.

> Then when the window is deleted we will just
UnregisterClass(GetClassName(hwnd)) and NOT have any GDI leaks.

...  because of not freeing the Window Class after destroying a window ?

There is no need for this. MSDN says, you can call UnregisterClass() after every
window destroying.

"If the class could not be found or if a window still exists that was created
with the class, the return value is zero. To get extended error information,
call GetLastError.

Before calling this function, an application must destroy all windows created
with the specified class. All window classes that an application registers are
unregistered when it terminates.

http://msdn.microsoft.com/library/default.asp?url=/library/en-us/winui/WinUI/Win
dowsUserInterface/Windowing/WindowClasses/WindowClassReference/WindowClassFuncti
ons/UnregisterClass.asp


> We have a GDI leak now because of this, so it will kill two birds with
> one stone.  Under NT or later this leak shouldn't be a problem, but
> 95 based OSes share a common 16-bit pool amongst all apps, and may
> run out causing really bad things to happen if the server is running
> for a long time.
>
> We also have a GDI leak on the HICONs which need to be properly
> disposed of before they're lost completely.
> With a separate class per window this will be easier, since no window will
share a HICON
> with another.

... but there are many more windows with the default x icon and not with the
icon of the basic application window. Fixing this means adding some stuff to
deal the stuff, the Window Class concept does.

I have some questions about this:

1. Does UnregisterClass() frees the assigned ICON or has it to be free'd
manually ?

2. The CreateIcon() and LoadImage() stuff does not frees the previous icon.
Could this not be fixed ? Does this not fix mostly GDI leaks ?

3. Every time a WMhints message comes in a new icon will be created. What about
checking if this icon was already created and avoid every time recreating ? The
pixmap id could be stored in the private window area.

> The class, name, and role can still be used for the 2nd chance
> iconification of windows (the LoadImage() call referencing xwin.ini).
>
You mean canceling the wm-hints pixmap features ? That means excluding all x
apps, which does provide such informations.

> I'll throw a patch together tonight for this unless someone beats me to it.

Any comments ?

Cheers

Ralf