C / C++ / MFC

4-Jan-05 1:24

Hey there...

I'm having a problem with MessageBox(HWND, char*, char*, UINT). I'm writing C++ to the WinAPI, no high level abstractions other than those that I roll (ie no MFC, ATL, or managed extentions).

I have a main window created with WNDCLASSEX. Durig WM_CREATE, a couple dialog boxes are created and displayed to help guide the user through a couple of setup steps. The problem lies in calling MessageBox(...) from any of these dialogs. Any attempt to display a MessageBox(...) results in a system beep, all GUIs lose focus, but the MessageBox never appears.

If I run the debugger, I can watch the system get to the MessageBox(...), execute it, return IDOK, then the debugger quits and lets the application resume, never executing any code that follows.

If I remove the calls to show and update the main window (in WinMain(...)), then the dialogs can display MessageBox(...) as normal. The Dialogs are also able to call one another with no ill effects, regardless of whether or not I show the main window.

Now, I have a template I have written over time, which includes WinMain, WinProc(...), etc, so I just have to cut and paste to get an application started, and none of my previous applications have ever had a problem like this. I have spent days now, comparing this app to previous ones, and I simply cannot find a difference between the architecture and the calls (nor the way I use them).

I have tried everything I can think of, tweaking every dialog attribute there is, changing the calls and the order the are invoked. One other note, if I invoke a MessageBox(...) from within WM_CREATE, all is fine, its only after the ShowWindow() and UpdateWindow() calls that this behaviour starts to exhibit itself.

Has anyone ever seen this behavior before? Have any idea what it is that I could have done wrong this time?

Some code samples follw this post.

Thank you for reading all this and any help you might be able to offer

Dave

p.s. compiling with VC++ 7.1 on Win XP Pro

from WinMain....

// store the instance
DAT->hInst = instance;

MSG msg;
WNDCLASSEX wcex;
HWND hWnd = NULL;

// build the windows struct
wcex.cbSize = sizeof( WNDCLASSEX );
wcex.style = CS_HREDRAW | CS_VREDRAW;
wcex.lpfnWndProc = (WNDPROC)WinProc;
wcex.cbClsExtra = 0;
wcex.cbWndExtra = 0;
wcex.hInstance = DAT->hInst;
wcex.hIcon = LoadIcon( DAT->hInst, (LPCTSTR)ICO_GLOGO );
wcex.hCursor = LoadCursor( NULL, IDC_ARROW );
wcex.hbrBackground = (HBRUSH)GetStockObject( GRAY_BRUSH );
wcex.lpszMenuName = (LPCTSTR)MENU_MAIN;
wcex.lpszClassName = gas::sAPPNAME.c_str();
wcex.hIconSm = LoadIcon( wcex.hInstance, (LPCTSTR)ICO_GLOGO );

if( !RegisterClassEx(&wcex) )
{
MessageBox( NULL, "Error Registering Window: Need NT?", "Application Error", MB_ICONERROR | MB_OK );
}
else
{
hWnd = CreateWindow( gas::sAPPNAME.c_str(), std::string(gas::sAPPNAME + " " + gas::APPVER).c_str(), WS_OVERLAPPEDWINDOW, CW_USEDEFAULT, 0, CW_USEDEFAULT, 0, NULL, NULL, DAT->hInst, NULL );
if( !hWnd )
MessageBox( NULL, "Error Creating Window: NULL Handle Returned!", "Application Error", MB_ICONERROR | MB_OK );
else
gas::Data::hMain = hWnd;
}

// everything is done, give the user the application window
ShowWindow( hWnd, showcmd );
UpdateWindow( hWnd );

// welcome the user if they still wish to be
if( CFG->GetShowWelcomePrompt() && gas::Data::hWelcome ) {
ShowWindow( gas::Data::hWelcome, SW_SHOW );
SetFocus( gas::Data::hWelcome );
}

while( GetMessage( &msg, NULL, 0, 0 ) > 0 )
{
if( !IsDialogMessage( DAT->hSplash, &msg ) &&
!IsDialogMessage( DAT->hDataSrc, &msg ) &&
!IsDialogMessage( DAT->hWelcome, &msg ) )
{
TranslateMessage( &msg );
DispatchMessage( &msg );
}
}

return( static_cast<int>( msg.wParam ) );

from WinProc::WM_CREATE

case WM_CREATE:
{
// gonna do a simplified splash screen for now
// later this is where we'll retreive startup data
// and perform synchronization
gas::CreateSplashDlg( hwnd );
if( gas::Data::hSplash )
{
ShowWindow( gas::Data::hSplash, SW_SHOW );
SendMessage( gas::Data::hSplash, WM_COMMAND, MAKESHIFT_TIMER, 0 );
}

if( CFG->GetShowWelcomePrompt() )
{
gas::CreateWelcomeDlg( hwnd );
if( !gas::Data::hWelcome )
MessageBox( NULL, "Error: Failed to create the Welcome Prompt GUI", "System Error", MB_OK|MB_ICONERROR );
}
return 0;
}

From one of the dialog headers...

case BUT_DATASRC_ACTIVATE_ONE:
{
// which one do they want to activate
unsigned int index = (unsigned int)SendMessage( GetDlgItem(hwnd, LST_DATASRC_DEFINED_SRC), LB_GETCURSEL, 0, 0 );
if( index >= 0 && index < DAT->GetDataSourceCount() )
{
gas::DataSource * ds = DAT->GetDataSource( index );
ds->active = true;
PopulateListBoxes( hwnd );
}
else
{
MessageBox( NULL, "You must select a data source before you can activate it", "Application Error", MB_ICONERROR|MB_OK );
}

processed = TRUE;
break;
}

Blake Miller4-Jan-05 8:51

Blake Miller

4-Jan-05 8:51

I usually NEVER pass in NULL as the first argument. Just for grins, try using the desktop window retreived with the GetDesktopWindow() function and see if that works for you.

realloc4-Jan-05 11:51

4-Jan-05 11:51

Hey Blake...

Thanks for the reply. I did as you instructed and and expereinced the exact same behavior.

Regarding the HWND arg, I typically pass in the handle of the GUI invoking the MessageBox(), but in an attempt to solve this I was pouring through Petzold, and one of the things he notes is that NULL makes it so that the MessageBox() isn't owned by anyone. I have been thinking I have some sort of message pump issue with the message making its way to the main window, so I thought I'd try eliminating ownership.

Honestly, I am at a loss... I have been comparing this code to half a dozen of apps I've written and I just can't find a difference. I invoke MessageBoxes from dialogs all the time.

Thanks for taking a look and adding some input

Dave

Blake Miller4-Jan-05 12:07

Blake Miller

4-Jan-05 12:07

Generally, invoking the message boxes from dialogs is NOT a problem.
What I am beginning to suspect is that if this current work is done when your application is starting up, you don't have a message pump for your program's primary thread yet. Microsoft's most recent guidelines and documentation infer that a thread does not necessarily have a message pump associated with it. A message pump is not created until the first call that would post, send, or attempt to retreive a message is made. You now might try putting a blank PeekMessage at the beginning of your program, using NULL as the 'window handle' to see if that will help your program get a message pump started. Then the message boxes might work after that call has been made.
A program's primary thread normally gets the message pump started when it first enters the get/translate/dispatch message loop. Anyway, it is just an idea of what I would be trying at this point to make it work.

realloc4-Jan-05 13:56

4-Jan-05 13:56

Hi Blake...

This was a good thought, I was hopeful. I tried at the very begginging, after the window creation and in the WM_CREATE... nada.

I did however take a cue from you post. After the failed attempt with the peek, I removed all calls from the WM_CREATE, let the main window complete (let it get a WM_SIZE and WM_PAINT). Added a menu and then invoked the dialogs via the menu after the main window had time to process a few messages. The behavior was unchanged.

I've been running diff after diff trying to find where I strayed from past projects and just can't find it. So I am thinking that I should start a new project and just rebuild piece by piece until I find where things go to hell. Instead of my template, I'll copy a project that works and edit it as needed to get it going.

Thanks for all the input, it was GREATLY appreciated!

Dave

realloc5-Jan-05 13:49

Problem with CRichEditCtrl

5-Jan-05 13:49

Just to follow up on this issue...

I fixed it, but still havn't solved it.

I created another project with my templates and got that working as normal. I then went back to the original project and commented out the entire main file.

I cut and pasted in the main file from the new project, made sure it still worked, and then proceeded to cut and paste my original code back into place line by line.

Esentially I am back to my original code, byte for byte unchanged, but it works... ??????????

I am 1000% confused, have never seen anything as annoying as this, but I am back in business again which is the most important thing for now.

Thanks for all your help!

Dave

Neelesh K J Jain4-Jan-05 0:27

Neelesh K J Jain

4-Jan-05 0:27

Hello Friends,
I had been posting my problems for the system beep and finally after alots of experiments I found the person who was responsible for the beep sound. It was the Clear() member function of the CRichEditCtrl class.
Now please can anybody tell why this member function is giving a beep sound (Default Beep) of the system properties.

Thanks in advance.

Neelesh K J Jain.

David Crow4-Jan-05 2:42

David Crow

4-Jan-05 2:42

At what point is the Clear() method getting called?

"Opinions are neither right nor wrong. I cannot change your opinion. I can, however, change what influences your opinion." - David Crow

Neelesh K J Jain4-Jan-05 2:47

Neelesh K J Jain

4-Jan-05 2:47

At the time of OnInitialUpdate() member function. I had used CFormView class where I am having the OnSize() member function also. What I observed is If I include the OnSize() member function then the beep is coming otherwise the beep won't come. But Main problem is that OnSize() member function is also required.

David Crow4-Jan-05 5:28

David Crow

4-Jan-05 5:28

I'm not able to reproduce this problem. In a new SDI project with the view derived from CFormView, I added a rich edit control to the dialog template. Running the program produces no beep. What else do I need in order for the beep to occur?

"Opinions are neither right nor wrong. I cannot change your opinion. I can, however, change what influences your opinion." - David Crow

Neelesh K J Jain4-Jan-05 16:49

Neelesh K J Jain

4-Jan-05 16:49

After creating the SDI, Add OnSize() member function, OnPaint() member function don't do anything in these functions and I require these member function also. Then the beep will come.