Advertisement

Blank button on taskbar

Started by April 25, 2000 01:08 PM
41 comments, last by mkoday 24 years, 7 months ago
iwasbiggs: Unfortunately, that is not the problem. The Win32 generated app from VC 6.0 uses DestroyWindow() in response to WM_COMMAND...ID_FILE_EXIT pair. And it uses only PostQuitMessage(0) in the WM_DESTROY handler.

mkoday: You should use UINT instead of unsigned for your WndProc's second parameter. Also, if the problem persists, it would most likely be in your GameEnd() code. You should release DirectDraw surfaces before DirectDraw, and also any palettes and clippers, etc. Not just DirectDraw, unless that's a wrapper class you created, in which case you should check the release code in those functions. I'm going to compile the source you posted, and see if it causes that problem.


OK, had to add in some things to get it to compile. Ran it 30 times and at no time did the blank taskbar button show up. Don't forget to link it with ddraw.lib and dxguid.lib. The parts that I modified are well labeled. Here's the modified code, which is a complete Win32 app:


// winmain.cpp


// ADDED
#include "windows.h" // change these to brackets
#include "ddraw.h"

LPDIRECTDRAW g_pDD = NULL;

char* ErrStr = NULL;


void Game_End();
LRESULT CALLBACK WindowProc(HWND, UINT, WPARAM, LPARAM);


template
inline void SafeRelease(PointerType*& pointer)
{
if( pointer != NULL )
{
pointer->Release();
pointer = NULL;
}
}


bool Init(HINSTANCE hInstance, int nCmdShow)
{
// Register the main window class

WNDCLASS wc;

ZeroMemory(&wc, sizeof(WNDCLASS));

wc.hInstance = hInstance;
wc.lpfnWndProc = WindowProc;
wc.lpszClassName = "My Window";
wc.hIcon = (HICON) LoadIcon(NULL, IDI_WINLOGO);
wc.hCursor = (HCURSOR) LoadCursor(NULL, IDC_ARROW);
wc.hbrBackground = (HBRUSH) (COLOR_WINDOW+1);

RegisterClass(&wc);

// Create the main window

HWND hTemp = CreateWindow("My Window", "Main Window", WS_OVERLAPPEDWINDOW,
CW_USEDEFAULT, CW_USEDEFAULT, CW_USEDEFAULT, CW_USEDEFAULT,
NULL, NULL, hInstance, NULL);

ShowWindow(hTemp, nCmdShow);

return (hTemp != NULL) ? true : false;
}
// ADDED


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();


// ADDED
Sleep(0);
// ADDED
}

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


// WindowProc
LRESULT CALLBACK WindowProc(HWND hWnd, UINT 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()
{
SafeRelease(g_pDD);

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





- null_pointer
Sabre Multimedia


Edited by - null_pointer on 4/30/00 7:59:38 AM
Damnit, ppl, it aint important. As someone pointed out very earlier, EVEN PROFECCIONAL PROGRAMS DO THIS!!!!!

Do you see something here? DINGDINGDING!!!! BUG IN WINDOWS, WHO WOULDA THOUGHT?!?!

Thats it. Just a bug. Happens sometimes, sometimes it doesn''t.... IT ISN''T IMPORTANT, CONTINUE WITH YOUR LIVES!!!
Advertisement
quote:
Damnit, ppl, it aint important. As someone pointed out very earlier, EVEN PROFECCIONAL PROGRAMS DO THIS!!!!!

Do you see something here? DINGDINGDING!!!! BUG IN WINDOWS, WHO WOULDA THOUGHT?!?!

Thats it. Just a bug. Happens sometimes, sometimes it doesn't.... IT ISN'T IMPORTANT, CONTINUE WITH YOUR LIVES!!!


You need to listen to what null_pointer is saying. He is a very intellegent person who knows what he's talking about.

This is not a bug in windows, it's a bug in the application. Just because "professional" games have this bug does not mean it's a Windows problem, or that it's OK. I don't like Windows much either, but for crying out loud, 99% of the time, the bugs are in YOUR code - not in Windows.

Your attitude is not the attitude any developer should have. If you know there is a bug in your code, YOU FIX IT. You don't pass the blame to the OS.

Josh
http://www.jh-software.com

Edited by - Josh on 4/30/00 12:14:47 PM
Joshhttp://www.jh-software.com
Are you saying even the biggest profesional programmers can''t solve this, becuase thats where i see it!

And DAMNIT, IM RIGHT WHEN I SAY IT...

A I N '' T I M P O R T A N T ! ! ! !



Nothing bad can result if you don''t fix this! ITS JUST ANNOYING, THAT ALL!! If you''re spending all your time trying to fix a super non -critical bug in your code when even profesionals have trouble with it, YOU HAVE YOUR PRIORITIES IN THE WRONG PLACE!!!
Zipster: It is important. Every bug is important. It has been well documented that Windows programmers tend to blame Windows quite often for their own mistakes.

Let''s go through this problem logically. First, if it was a bug in the Windows shell (it happens in both 95 and 98), then the problem would be with the DLLs which MS could have fixed about 5 years ago. Obviously, it is not a problem with all windows and all programs, because it only happens to some programs, and mostly games. Why games? Is it a bug with the window styles then? No, I don''t think so...that would have been fixed long ago, too. (And quite easily, I might add.) It is very doubtful that MS would have left the same bug present when releasing Windows 98, and even more doubtful when you how important (and highly visible) the taskbar is.

So, where does that leave us? Well, we have another weak point in the Windows bug theory -- we''re getting these "bug reports" from a couple of irritated Windows programmers who all encounter the same problem... Sound like a recipe for bias and assumptions?

Further, I have seen the code from "industry experts" and they all have problems or bad coding practices that they carry over. Even Andre LaMothe, some of the GameDev staff, *looks around nervously* all have points or theories that I really disagree with. I disagree with them on points of logic, not just personal preference. Most of it is not major, but I would say that out of all the code snippets and comments in this forum site since its inception, I would call only 2 or 3 people good programmers. That doesn''t even include myself.

There are TONS of myths floating around about Windows programming. For example, there is some kind of general misconception that games shouldn''t let users interact with other apps, that Windows hampers performance, etc. The books from the "pros" often teach you little more about Windows than how to replace GetMessage() with PeekMessage() and insert your game''s frame function. Not bad for starters, but from pros? You would think that a good Windows game programmer would be a good Windows programmer, but it is usually quite the opposite (shouldn''t be, but it is). It is very discouraging (as I''m sure you''ve found) that very few Windows game programmers on this web site know much about such a (relatively) simple thing as blitting using the GDI.

Why does this happen? Game programmers are very tempted to adopt bad programming habits (or cool hacks, as they are sometimes called). To this I say: TAANSTAFL. 2-bit hacks can make nothing better than 2-bit programs...


*steps down from the soap box*


That''s why I wouldn''t believe it, unless it was found in the Microsoft KB. Considering all the obscure bugs that get reported in the KB, I should think a simple problem with window styles would have been documented there. But no one can offer a link, and my browser''s messed up for some reason. It can''t do searches, like the one on GameDev for topics. I don''t have time to search the KB, or to learn how. I have read several links to the KB on other problems, and I know that it is EXTREMELY thorough. In fact, I would not even believe the bug if it was found in a programming magazine or website, however reputable it may be.

To test the program and the method for starting up/shutting down to see if it contained bugs, I copied and pasted the code, added in some dummy functions and code to create a window, and ran it 30 times (30 TIMES!) and I still couldn''t get the problem to occur. From what I know about other programs with the same problem, it occurs very often (like 9 times out of 10). Perhaps it is more or less random, but 30 times ought to be plenty of chance for it to happen.

Considering all of this, which would you say is more likely? A bug in Windows or a bug in several Windows programs?


- null_pointer
Sabre Multimedia
Is it me, or is the point I''m trying to make not clear enough. THIS BUG HERE, RIGHT HERE, IS NOT IMPORTANT!! IF YOU FIX IT, GREAT, YOU JUST WASTED TIME ON SOMETHING STUPID RATHER THAN SOMETHING IMPORTANT. IT CAUSES NO HARM, NO DAMAGE, JUST MAYBE A LITTLE ANNYOANCE. TRY FIXING SOMETHING MORE IMPORTANT, OR COMING UP WITH OTHER THINGS.

Is my point clear now?
Advertisement
Zipster, you are not seeing the whole picture here. Since this bug is not a Windows bug, it is an application bug. This means that the application is doing something it''s not supposed to (or not doing something).

Just because the only results of this bug you see is a phantom button on the taskbar does not mean that''s all the bug is. Odds are, something is going wrong. When something goes wrong, that''s BAD.

Do YOU get MY point? It''s like an iceburg... you can see the tip poking out, but do you know how deep it goes under the water? ANY BUG, no matter how insignificant it may appear, should be handled.

It is true that this is not a show stopper bug, but it is doing something screwy and it is probably making the user''s computer unstable. That is definately NOT a good thing and should be taken care of.


Josh
http://www.jh-software.com
Joshhttp://www.jh-software.com
Well, I think my problem was that I was calling the GameEnd() function from my WM_DESTROY message when I was already taking care of that in the actual message loop. Also I added the Sleep(0); code (btw, what exactly does that do?), and I tested it about 20 times, and got no blank button. Thanks to everybody that helped, this was really making me mad.

email: chickawow@netzero.net

annex software: http://annexsoftware.cjb.net
Sleep(0) actually releases the time slice of the running thread to give other threads a chance to run..

It is the replacement for Yield which is now obsolete

Zipster ?? .. you are definitly taking the WRONG approach to developement. Any bug is important to fix.

glad to help. maybe someone can sum up this bug as an example in a new "bugs are important" article
___________________________Freeware development:ruinedsoft.com

This topic is closed to new replies.

Advertisement