Jump to content
  • Advertisement
Sign in to follow this  
Sepiantum

MessageBox is causing me severe pains

This topic is 2581 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

If you intended to correct an error in the post then please contact us.

Recommended Posts

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?

Share this post


Link to post
Share on other sites
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.

Share this post


Link to post
Share on other sites
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.

Share this post


Link to post
Share on other sites

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.

Share this post


Link to post
Share on other sites
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.

Share this post


Link to post
Share on other sites
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.

Share this post


Link to post
Share on other sites
Sign in to follow this  

  • Advertisement
×

Important Information

By using GameDev.net, you agree to our community Guidelines, Terms of Use, and Privacy Policy.

GameDev.net is your game development community. Create an account for your GameDev Portfolio and participate in the largest developer community in the games industry.

Sign me up!