MessageBox is causing me severe pains

Started by
5 comments, last by Sepiantum 12 years, 5 months ago
My sig contains the SF page with the SVN repo with all my code, so I'll only post snippets. This is what I have:

//Removes a window with specified ID from the list. Called from CWindow* upon receiving WM_DESTROY
bool ExtendedWindowsAPI::ExtendedWindows::CWindowManager::RemoveWindow(int ID){
//Check bounds
if(this->inbounds(ID)){
//Removal code
//Properties should be removed when receiving WM_DESTROY
pWindows[ID] = nullptr; //We don't want to delete in case if user wants to recreate the window
MessageBox(NULL, L"Removed a window", L"Yay", MB_OK);
return true;
} else {
//... We should NOT be here. How do you get an invalid ID from a window
//That easily retrieves its ID?
this->RaiseErrorMessage(NULL, "CWindow apparently managed to return an invalid ID");
return false;
}
}


I get to the removal code all right, but the MessageBox gets ignored completely. I can set a breakpoint on it, no message box is created. I know that the previous statement is executed because I was able to add the window to list, create from list, and the destructor checks to see if everything is set to nullptr and it is. I honestly have no idea what's wrong. Any help guys?
Follow and support my game engine (still in very basic development)? Link
Advertisement
Most likely there are bugs elsewhere from what we see here. The assumption that your code must be working correctly because the ID has been nulled is a mistake I used to make all the time myself. Set the breakpoint on return true, see if you are actually stepping to that part of your code or not. Also try removing the L's, been a while since I used C++ but from what I remember MessageBox() by default is calling the standard 8bit ASCII characters, meaning passing a normal const char * "this is normal" works as is. Type casting them with the L prefixing the "string" may be causing problems if you are getting to this stage. Also I know it sounds silly but the MessageBox itself is set to a NULL parent, are you sure it's not showing up behind your window? This happens a lot the message box works fine but it is hidden behind your app, theres no tray icon to show you it's there... You close the program thinking it wasn't even there. Try minimizing everything when you break on return true (one by one of course) and make sure the little bugger is hiding somewhere.

Dan Mayor

Professional Programmer & Hobbyist Game Developer

Seeking team for indie development opportunities, see my classifieds post

I'm using Unicode, so L is necessary. I've hit true. If I don't hit true, then shouldn't the process hang? There is no window showing up behind my window because I null the reference in the window manager right before WM_DESTROY finishes up. It also doesn't return false. If it did, I would get an error message as a messagebox. I've attached a pic showing what it's like on the MessageBox statement. No message box shows up before, on, or after that particular statement when stepping through code.

EDIT: Using RaiseErrorMessage also fails there. 64bit and 32bit compiles both fail.
Follow and support my game engine (still in very basic development)? Link
When is that code run? If a thread received WM_QUIT any MessageBoxes do not work anymore. That's actually by design.

Fruny: Ftagn! Ia! Ia! std::time_put_byname! Mglui naflftagn std::codecvt eY'ha-nthlei!,char,mbstate_t>


When is that code run? If a thread received WM_QUIT any MessageBoxes do not work anymore. That's actually by design.


That's odd. Are you saying that I message boxes don't work in a thread that uses PostQuitMessage(0)? I'm pretty sure it works because when I use delete pWindowManager right before returning in WinMain(), the destructor can still use a message box.
Follow and support my game engine (still in very basic development)? Link
He's saying that after PostQuitMessage, the next call to a message getting function (Peek/GetMessage) will indicate it's time to exit. The next such call in your code happens to be inside MessageBox which immediately stops without doing anything. As that gobbles the message, there's no longer a quit message in the queue for future Get/PeekMessage loops be they in other MessageBox-es (which is why others work) or your own one.

This is one of the reasons why using MessageBox for debugging isn't recommended. Use OutputDebugString or debugger tracepoints instead and you get all of the messages with none of the clicks, message queue mutations, or other associated MessageBox guff.
So I should PostQuitMessage(...) right before I break from the switch instead of calling it and returning some superclass function. And I'll use OutputDebugString. Thanks all.
Follow and support my game engine (still in very basic development)? Link

This topic is closed to new replies.

Advertisement