It seems to me that this is something that should be looked at more. It is perhaps something to do with the way Windows handles things? Whatever it is, it is making me mad,

email: chickawow@netzero.net

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

I'm using win98.

I found that calling "CloseWindow()" in the WM_DESTROY will cause this problem (this is by the way, a definite bug in windows codes).

CloseWindow does exactly what you think it wouldn't. CloseWindow is for Minimizing the window (not closing).

I don't do much for a WM_DESTROY command, just to DestroyWindow() of my child windows I might have created excplicitly (like editboxes), post the quit message and return 0;

In WM_DESTROY.... Call only the post quit message- this will exit the program loop. Then in some code after your loop, you should then free up surfaces and do the remainder of your quit code. This way you will never redo the same closing code twice.
So in other words: don't put surface and direct draw destroying in your wm_destroy message of your window, only put the postquitmessage. Then in the main function and after your message loop (which will be broken from with WM_DESTROY that the user called) put your surface releasing.

I haven't ever had a problem with my code since I started organizing my code like this. Never handled the WM_CLOSE either.

Edited by - iwasbiggs on 4/28/00 6:40:38 PM

Note: This has nothing to do with the original problem.

I just thought that since a couple people have said they don't handle WM_CLOSE, I'd explain why I do. (I have this strange feeling that people think I'm doing this uselessly, and I'd like to clear it up.)

My app is essentially one main window and one rendering window. The main window never opens, it just sits in the taskbar. The rendering window needs to be destroyed when the app loses focus, or certain cards can't regain the rendering context correctly. However, when the 'X' button on the rendering window is pressed, I need to grab the WM_CLOSE and close the entire app instead of just the rendering window.

I really recommend using two windows like this if you'll be destroying and recreating your window at all. It has a lot of advantages.

Edited by - Ampere on 4/28/00 10:16:46 PM

I can kind of see why it bothers you, but it it not such a big deal. I get it all of the time, not just with my programs, but with Q3 and UT!!! I definitely think it is a bug in Windows 98 (I never used to get it in 95, and I haven''t seen it in 2000). Trust me, no one will think any less of you if your program leaves a little blank task bar box.

-Icarus

Yeah, me too. I think it''s something to do with Windows 98.




Lack

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

I''ve been programming in Windows 98 since last year -- never, ever had that problem. Before that, I programmed in Windows 95. Never had the problem then either. As I said before, it is 1000x more likely that the bug is in your program. Windows programmers are notorious for doing things without checking the docs and then blaming Windows when something doesn''t work. Further, this occurred quite a bit when Windows 95 came out, when programmers were getting used to a re-written API.

It is not hard to see why there are many commercial programs with the same problem -- people just don''t learn or don''t study the docs enough. Just because someone can program Unreal or whatever does NOT make them a good Windows programmer. If you are making a game in Windows, then make a Windows game! . Lots of people will tell you to "screw" Windows when you make your game, but that''s just ignorance. Windows is by far the most abused OS. It''s not perfect, but it''s stupid to expect Windows to clean up after your mistakes. Windows does a lot of things towards keeping programs separate, but it certainly cannot keep you from screwing up your own code.

Icarus: Stop saying things like that. If you can''t fix it, just ask. It is NOT good to leave a blank window on the taskbar, as it does confuse the user and disrupt the function of the taskbar. Don''t work around it or ignore it, just fix it. Even minor problems should be fixed, or you will carry them through every app that you make.


Why not post your source, mkoday? There are a 101 things that could go wrong in startup and shutdown code. You can post a stripped-down version (i.e., only initialization and shutdown code) if you think someone will steal your code. And, what about moving your shutdown code after the main message loop. Did it work?



- null_pointer
Sabre Multimedia

Actually, null_pointer, it is a bug in Windows 98. It''s been documented. I used to have Windows 95 and never had that happen, but once I went to 98, it started happening all over the place. Not just my programs (actually, not my programs) but professional programs and games do it all the time. It''s a fact, the problem lies with Windows 98.


Jason Wood
Creator of TIMELINE
http://timeline.50megs.com

Eternal Chrono: The bug started with Windows 95. It happens in Windows 95. I could send you programs that do it in Windows 95 (old Creative Labs install programs (i.e., AWE64 days), but they''re copyrighted. I''ve never run into the problem. Where is it documented? In this post? You''ve got to be kidding me, if you think I''d believe a couple of disgruntled Windows programmers about bugs in the Windows 98 GUI...


- null_pointer
Sabre Multimedia

Ya, here is some code: (btw, i still get the blank button with this code)

// WinMain
int APIENTRY WinMain(HINSTANCE hInstance,
HINSTANCE hPrevInstance,
LPSTR lpCmdLine,
int nCmdShow)
{
MSG msg; // message variable

if (!Init(hInstance, nCmdShow)) { // call the Init function
Game_End();
return false;
}

//testMap.Grid[move_x][move_y].WalkInto(pic);

while (true)
{
// Check for new messages to remove and process

if (PeekMessage(&msg, NULL, 0, 0, PM_REMOVE))
{
// If we recieve a quit message, break ou the of the main loop

if (msg.message == WM_QUIT)
break;

// Translate and dispatch the message to the MsgHandle function

TranslateMessage(&msg);
DispatchMessage(&msg);
}

// Update game logic and render one frame

testMap.Draw();
}

Game_End();
return (msg.wParam);
}



// WinodowProc
LRESULT CALLBACK WindowProc(HWND hWnd, unsigned uMsg, WPARAM wParam, LPARAM lParam)
{
switch (uMsg)
{

case WM_DESTROY:

PostQuitMessage(0);
return (0);

break;

case WM_KEYDOWN:
switch (wParam)
{

case VK_ESCAPE:

DestroyWindow(hWnd);

break;

default:
break;
}

default:
return DefWindowProc(hWnd, uMsg, wParam, lParam);
}
return 0L;
}



// GameEnd()
void Game_End(void)
{

SafeRelease(g_pDD);

if (ErrStr) {
MessageBox(NULL, ErrStr, Caption, MB_OK);
ErrStr = NULL;
}
}

email: chickawow@netzero.net

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

I was just sifting through the code, and there a few things that were missed:
on the windowproc:
-when pressing VK_ESCAPE:
--put a PostQuitMessage(0); *this only*

in the game_end():
-release DD and surfaces
if (hwnd){
DestroyWindow(hwnd);
hwnd = NULL;
}

sorry I forgot to mention that I delete all created windows in the gameend routine (which is only called in the winmain function).

If you're still having windows problems (and this is the only window you explicitly created)
try putting "return 0;" before each break; statement in the windowproc routine.

If you're still having difficulty post the code again with the fixes. I'm almost out of ideas as to what else it might be.

Oh yeah! forgot to mention, if you want to exit the application (and you've already entered the game loop), always use PostQuitMessage(0); from now on.

Edited by - iwasbiggs on 4/29/00 10:29:41 PM