WM_DESTROY, WM_CLOSE, ...



  • Hi!

    I've got the following problem: my windows stay on the taskbar after my app exits; calling CloseWindow() before DestroyWindow() removes that problem, but then windows #&$!*§ animates the windows to the taskbar before closing them. Every single one of them - and since there's a chance that I have a lot of windows on screen that is so totally unacceptable.

    So, after googling around and finding no helpful information whatsoever (why are there 3.2 quadrillion copies of the same tutorial on how to open a window when so many ides have a code snippet doing exactly that anyway?) I thought I'll ask here. I need information on why a window stays in the taskbar after calling DestroyWindow() from the thread that created the window or how to CloseWindow() a window without the animation. Thanks for any help.

    -Mike



  • I dug up an old Windows thingy I have. In there I have this:



    LRESULT CALLBACK WndProc(HWND hwnd, UINT Msg, WPARAM wParam, LPARAM lParam)
    [...]
    		case WM_CLOSE:
    			DestroyWindow(hwnd);
    		break;
    		case WM_DESTROY:
    			PostQuitMessage(0);
    		break;
    [...]
    


  • Hmm - found that in old code of myself and in a lot of examples via google. The problem is that the windows are shown in the taskbar even after the app is no longer running. When I click the icon in the taskbar Windows somehow notices that they are no longer alive and removes them. I have no idea why, but I'll keep trying, got another idea.



  • @vertex said:

    Hmm - found that in old code of myself and in a lot of examples via google. The problem is that the windows are shown in the taskbar even after the app is no longer running. When I click the icon in the taskbar Windows somehow notices that they are no longer alive and removes them. I have no idea why, but I'll keep trying, got another idea.
     

    From very dusty memory, I think if you throw SW_HIDE at the window using the ShowWindow() function, it will disappear from the taskbar. Can't vouch for that stopping any animation though as it disappears.

     



  • Doesn't stop the animation. It's really frustrating since windows get destroyed cleanly while the application is running, only when exiting and destroying all open windows they stay in the taskbar (I use the same destroy code in both cases). Maybe I'll put in a sleep() and a // FIXME and move on to more important things. sigh



  • I figured it out ... finally. For everyone who needs to do the same thing, this little combo works:


    ShowWindow(hWnd, SW_HIDE);

    CloseWindow(hWnd);

    DestroyWindow(hWnd);


    To think that this took me about three days to figure out - I should be ashamed. ShowWindow actually works without animation, but it doesn't remove the window. CloseWindow removes the window from the taskbar without animation when the window is hidden.



  • That'll still leave the taskbar buttons there if the program crashes or otherwise ends up having windows destroyed without going through the CloseWindow hack. Better to actually fix the bug instead of just working around it. [url=http://blogs.msdn.com/oldnewthing/archive/2003/12/29/46371.aspx]This page[/url] explains how the taskbar can get confused about which windows should have a button and as a result end up with orphaned buttons when the windows go away.



  • @Goplat said:

    This page explains how the taskbar can get confused about which windows should have a button


    Why doesn't the taskbar pay attention to all windows as they come and go?

    Answer:
    Because that would be expensive. The filtering out of windows that
    aren't taskbar-eligible happens inside USER32 and it then notifies the
    taskbar (or anybody else who has installed a WH_SHELL hook)
    via one of the HSHELL_* notifications only if a taskbar-eligibie window
    has changed state. That way, the taskbar code doesn't get paged in when
    there's nothing for it to to.

    Yeah, because so many Windows systems spend their time with the taskbar code swapped out, and window state changes happen really frequently. Sheesh. I knew it was broken, but I didn't know it was broken for such an lame reason.

    Premature optimisation remains the root of all evil. And also a lot of stupid.



  • please prove that this is premature optimization and not the result of a performance analysis of a running system. 



  • Thanks for that MSDN link ... good to know that.



  • @tster said:

    please prove that this is premature optimization and not the result of a performance analysis of a running system. 

    It is an operation that occurs only once every time a window changes state. Windows change state at a rate of less than once per second, under any reasonable workload. The time needed to load a few pages from the swap image is on the order of 10ms or less, and this operation would occur only for the first such event, since after that it would be in core. Therefore, this cannot create any performance problems, so no correct performance analysis could identify it as something in need of optimisation, so one was not performed.

    QED 



  • do here are my options.   I either agree with you, who just made that shit up off the top of your head.  Or I believe the someone that actually worked on it....  This is a tough decision!

    You do realize that they are refering to all windows.  This will include hidden windows.  An app might spawn lots of hidden windows for any number of reasons.  Perhaps what they found was that startup took a much longer time because of all the hidden windows that were being created by various startup applications. 



  • @tster said:

    An app might spawn lots of hidden windows for any number of reasons.
    On top of that isn't every button, text area, and what-not a window in Windows?



  • @Lingerance said:

    @tster said:
    An app might spawn lots of hidden windows for any number of reasons.
    On top of that isn't every button, text area, and what-not a window in Windows?

    For the purposes of this discussion, no. 



  • @asuffield said:

    Yeah, because so many Windows systems spend their time with the taskbar code swapped out,
    Considering the amount of RAM the typical computer had in 1995 (The 486 I had then had 16 MB; Windows 95's minimum requirement was only 4 MB) - yes, the taskbar likely would be swapped out if you used a large program and didn't switch any tasks.

    [quote
    user="Lingerance"]@tster said:
    An app might spawn lots of hidden
    windows for any number of reasons.
    On top of that isn't every
    button, text area, and what-not a window in Windows?
    For the purposes of this discussion, no.[/quote]You said that the taskbar ought to be notified of [b]all[/b] window state changes (because filtering out non-taskbar-eligible windows would be a "premature optimisation"). Child windows are still windows. And they get created/destroyed a lot more than top-level windows.



  • @Goplat said:

    Considering the amount of RAM the typical computer had in 1995 (The 486 I had then had 16 MB; Windows 95's minimum requirement was only 4 MB) - yes, the taskbar likely would be swapped out if you used a large program and didn't switch any tasks.

    Irrelevant to XP. There is no shared code, it descends from NT instead.


    @Goplat said:

    You said that the taskbar ought to be notified of all window state changes (because filtering out non-taskbar-eligible windows would be a "premature optimisation"). Child windows are still windows. And they get created/destroyed a lot more than top-level windows.

    You are confused about how the win32 API works. For the purposes of this discussion, so-called "child windows" are irrelevant.


Log in to reply
 

Looks like your connection to What the Daily WTF? was lost, please wait while we try to reconnect.