Blank button on taskbar

i''ve noticed this even in "professional" games, so it MUST be ok
this problem has been inconsistent in my code as well. i can''t seem to figure out what makes it appear and disappear. i think it may have something to do with how the WM_DESTROY message is handled, but i don''t really know.

crazy166
some people think i'm crazy, some people know it

What I am doing on WM_DESTROY is calling a function that releases DD surfaces and such, then doing PostQuitMessage(0);. Is that the best way to do it?

email: chickawow@netzero.net

annex software: http://annexsoftware.cjb.net

This may seem a bit hackish, but I do a ShowWindow(hWnd, SW_HIDE). I think I''ve got that in my WM_DESTROY case, but I can''t remember. Never had any problems from it.

quote:

---

This may seem a bit hackish , but I do...

---

OOOOH, I like that word "hackish"! I think im gonna steal it . (Or use it if he didn''t make it up )

That ShowWindow(hWnd, SW_HIDE); didnt work. Does anybody else have any ideas? Maybe somebody that has had this problem before and fixed it?

email: chickawow@netzero.net

annex software: http://annexsoftware.cjb.net

The ShowWindow() definitely fixed it for me. If there still aren''t any answers by tonight, I''ll check through my code and find out exactly where I call it.

In addition the the blank button, sometimes the desktop''s icons get put into an imaginary square. I am setting the display mode to 640x480, and this may have something to do with the desktop thing. The icons are in the upper-left hand corner and nowhere else.

email: chickawow@netzero.net

annex software: http://annexsoftware.cjb.net

Unfortunately, the call was right where I thought it was, at the end of my WM_DESTROY handler. So I guess if that didn''t work for you I don''t have any other suggestions to offer. It clearly is the solution in my code. I can comment it out and immediately start getting blank buttons.

As for moving desktop icons, is the desktop ever being shown while in 640x480? Do you change the resolution after creating your window, and change it back before your window is destroyed (or minimized, or hidden, etc)?

I use to experience the blank buttons when I try to force quit the application in fullscreen mode when an error occurs..

It has to do something with the wrong deallocation order of Directdraw, DirectInput, page flipping, application focus, Messageboxes and DestroyWindows(..).


I cannot remember the exact solution as my code is totally in a mess, but I did manage to solve the problem. (I was working with the above when I experienced the problem, but I ''m not sure which part of the code that actually fixes it)

I do not think it is "OK", even it happens in professional games.

Ampere: When exactly do you do the ShowWindow(hWnd, SW_HIDE);? Right before the PostQuitMessage(0);?

email: chickawow@netzero.net

annex software: http://annexsoftware.cjb.net

I believe it just went:

ShowWindow(hWnd, SW_HIDE);
PostQuitMessage(0);
return 0;

Something to that effect anyway.

Oh, I always thought it had something to do with MSVC++ compiling. Well, I have an OpenGL skeleton that does the same thing. If there''re too many of them, the system seems to become unstable (as if Windows wasn''t unstable enough!) I use

case WM_CLOSE: PostQuitMessage(0); return 0;

Maybe a break statement would help?


Lack

Christianity, Creation, metric, Dvorak, and BeOS for all!

I prefer to put a DestroyWindow() in my WM_CLOSE so that I only have one path out, so to speak.

Well, here are the things that I have right now that deal with window closing and destruction:

case WM_DESTROY:
Game_End();
ShowWindow(hWnd, SW_HIDE);
PostQuitMessage(0);
break;

case WM_CLOSE:
DestroyWindow(hWnd);
break;

and i still get the blank button. Wierd.

email: chickawow@netzero.net

annex software: http://annexsoftware.cjb.net

I've never had a problem with it before -- it's gotta be a bug in the Windows 95 GUI (a really early version) or a bug in your code. The latter is 1000x more probable... BTW, some commercial apps and games (mostly stuff around the launch of Windows 95, meaning 16-bit) say this is fine, but we all know it isn't!

If it was a bug, you could try searching the MS KB, as I'm sure something like that would have made it in there. Otherwise, why not post some code? Can't rule out all the possibilities...without knowing the code...


You must've posted right when I was writing -- I'll look at the code now. Well, here's what I do in my WM_DESTROY handler:


PostQuitMessage(0);
return DefWindowProc(...);



I never handle a WM_CLOSE message. If you look at the Win32 EXE skeleton code from VC, you'll find that it doesn't either. If you want to quit the app, you just call DestroyWindow on the main window handle and you're set.

---

- null_pointer
Sabre Multimedia


Edited by - null_pointer on 4/27/00 4:43:59 PM

I tried this code about 15 times and the blank button was there twice. It''s odd how it would appear sometimes, and not others.

case WM_DESTROY:

Game_End();
ShowWindow(hWnd, SW_HIDE);
PostQuitMessage(0);
return DefWindowProc(hWnd, uMsg, wParam, lParam);

break;

email: chickawow@netzero.net

annex software: http://annexsoftware.cjb.net

I''m pretty sure it''s just the App in the process of killing itself. If you have large quantities of surfaces, or other allocated data, it might take a few seconds to go away.

If you process WM_DESTROY it should return 0. In most cases only messages not explicitly handled by the app should use DefWindowProc().

Buster: My app''s small, even has no textures loaded, and these things stick around indefinitely.


Lack

Christianity, Creation, metric, Dvorak, and BeOS for all!