ASSERT when opening dialog box

[bkelly]

Environment: Windows XP Pro, Visual Studio 2008, MFC, C++

I have regressed since my last post and now am getting an Assert when I click a button to open a second dialog box.
Note: I cannot cut and paste from my work computer to my internet computer so please forgive any obvious typos.
In the main window .h file I have:

…
C_Logging_Control *mp_C_Logging_Control; // the class of the new dialog box
…

And in the .cpp file I have:

BOOL CAR2_Messasge_AppDlg::OnInitDialog() 
{
…
    // create the class that owns (??) the new dialog
   // I put a break point in C_Logging_Control constructor and it looks ok as it starts up.
mp_C_Logging_Control = new C_Logging_Control;
…. }

….  Much later, the code to open the new dialog
Void C_AR2_Messasge_AppDlg::OnBnClickedBtnOpenLogControl()
{
      // I will discuss these four lines in a moment
   bool test = false;
   bool window_value = ::IsWindows( m_hWnd);
   if( m_pCtrlSite != Null )
      test = true;

   if( mp_C_Logging_Control != NULL )
      mp_C_Logging_Control->ShowWindow( SW_SHOW );
}

Everything works until the call to ShowWindow which generates an ASSERT. I step into the ShowWindow code and the assert is in winocc.cpp and the code is:

BOOL CWnd::ShowWindow( int nCmdShow )
{
   ASSERT( ::IsWindow( m_hWnd) || (m_pCtrlSite != Null) );
…
}

This is the ASSERT that halts everything.
I took that ASSERT line of code, broke it up, and put it into my code that calls ShowWindow. That’s the four lines where I said they would be discussed in a moment.
I was a little bit surprised that it compiled, but that’s cool.
Bool window_Value is true after the call to IsWindows( m_hWnd )
As I read it, that means that the assert gets a true and should not bomb out.

So,…, are those four noted lines valid when I put them in my code?
Can someone detect the error on my part?

After another hour of work, the answer to the first question is No! Here is why:
I copied winocc.cpp into my project, adjusted its include files to reference the normal place, then broke up the ASSERT and discovered that ::IsWindow( m_hWnd) returns a false. Its OK in my code, but once deep down into the dialog’s code, its not. (I think that is the case.)

But now I don’t know what that means or how to fix it. Can someone clue me in on this?

Thank you for your time.

EDIT: I just found someing in some example code that translates to this in my code:

 mp_C_Logging_Control->Attach( hWnd );

The problem is that I don'w know the general meaning of hWind and what I need to use in my code. Is this the answer or is it something else.

[MrViggy]

Before you can show a window ("mp_C_Logging_Control->ShowWindow( SW_SHOW )"), you must create a window. All you did was create a new instance of the object "C_Logging_Control". See the Create member function of the CWnd class.

Viggy

[GCDEF]

Any particular reason you're using new with mp_C_Logging_Control, instead of just making it a member? It's hard to say what's going on without knowing what mp_C_Logging_Control, but to show a dialog, you normally have to call either DoModal, or Create if you want a modeless dialog. Doesn't look like you call Create anywhere.

[Paul McKenzie]

The problem is that I don'w know the general meaning of hWind and what I need to use in my code. Is this the answer or is it something else.

An hWnd is the window handle. It is of type HWND, and HWND is how the OS knows about the individual windows that are created. Note that this has nothing to do with C++.

A C++ class is not a GUI window -- it is a C++ class. Looking at whether constructors are called and all of that doesn't mean anything in this context. C++ object construction doesn't equal window creation. Since your code never calls the functions (Create, DoModal) to create the Windows OS window (which the hWnd will represent), ShowWindow() isn't going to work.

Regards,

Paul McKenzie

[bkelly]

Any particular reason you're using new with mp_C_Logging_Control, instead of just making it a member? It's hard to say what's going on without knowing what mp_C_Logging_Control, but to show a dialog, you normally have to call either DoModal, or Create if you want a modeless dialog. Doesn't look like you call Create anywhere.

Because I tried to change another class from dynamic (i.e. new) to static and I immediatly started getting stackoverlow on startup. So I decided to have all the classes created dynamically. Any thoughts here will be appreciated.

[bkelly]

Hello Paul and all,
From the replies I see I have missed a bunch of stuff.

I have been unsuccessfully searching for a simple tutorial that describes how to use the built in GUI tools of Visual Studio to create a simple dialog and, maybe, setting a check box to the checked condition on startup. I want it simple. Once I see all the steps I have some hope of understand the whole process.
If you have a favorite link or forum thread that has this, please put that in a reply.

BTW: The new dialog will be opened from a button in the main dialog, not a menu or toolbar item.

[GCDEF]

Because I tried to change another class from dynamic (i.e. new) to static and I immediatly started getting stackoverlow on startup. So I decided to have all the classes created dynamically. Any thoughts here will be appreciated.

That's a terrible idea, and a habit you need to stop immediately. Solve the original problem.

[GCDEF]

Hello Paul and all,
From the replies I see I have missed a bunch of stuff.

I have been unsuccessfully searching for a simple tutorial that describes how to use the built in GUI tools of Visual Studio to create a simple dialog and, maybe, setting a check box to the checked condition on startup. I want it simple. Once I see all the steps I have some hope of understand the whole process.
If you have a favorite link or forum thread that has this, please put that in a reply.

BTW: The new dialog will be opened from a button in the main dialog, not a menu or toolbar item.

A lot of noobs seem to think you can learn C++ and Windows programming from a web site. You can't. It's way, way, way too complex for that. Most basic tutorial books are 1,000 pages or more and they just scratch the surface. Get a good book and work through it, but be prepared to spend quite a bit of time (months), just getting the basics down.

[Paul McKenzie]

I have been unsuccessfully searching for a simple tutorial that describes how to use the built in GUI tools of Visual Studio to create a simple dialog and, maybe, setting a check box to the checked condition on startup. I want it simple

I will second what GCDEF mentioned --

You can't learn C++ and Windows programming properly by merely going to a few web sites, unless that web site contains entire books in web form. It isn't like learning PHP or some other scripting-like languages, where you can get by with a cheat sheet which allows you to code 90% or more of whatever you want to accomplish. Learning the C++ language in general is one obstacle to overcome, learning Windows/MFC programming is another obstacle, and both require the requisite time to understand, and even then, you won't know everything.

Regards,

Paul McKenzie

[Paul McKenzie]

Because I tried to change another class from dynamic (i.e. new) to static and I immediatly started getting stackoverlow on startup.

So why were you getting a stack overflow? If you don't know why this error occurred, then what you have done is not a fix. Only when you know why a problem occurs can you apply a fix.

You should understand that for a language such as C++, you can throw "stuff" at a problem without any investigation as to why the problem occurs, with that "stuff" seeming to fix the problem. All that you really did do was possibly mask the problem --the problem still exists. Using "new" may have just masked the real reason why the problem occurred.

C++ programs contain an aspect that most languages do not have, and that is that you can create C++ programs that have undefined behaviour. You don't initialize a variable -- that program may run OK or run incorrectly. You're off by one byte in a memcp() or similar function, that program may work on 1,000 machines and crash on machine 1,001, etc. Other languages either detect these mistakes at build time, or at runtime, you are guaranteed a crash with a nice report of what failed. Not so with C++.

That's why it's imperative that all runtime issues that you have must be investigated and discovered why they occur. Then you create the fix with this information.

You need to set everything back to the way it was, and actually diagnose and fix the issue, otherwise your program is by definition unstable. Unstable meaning that you had a problem with the program, didn't diagnose it, wrote some code not knowing what it would result in, and magically the problem seemed to have gone away without you knowing anything else. That type of "fix" wouldn't be accepted by any C++ programmer, whether amateur or working in the industry.

Regards,

Paul McKenzie

[bkelly]

So why were you getting a stack overflow? If you don't know why this error occurred, then what you have done is not a fix. Only when you know why a problem occurs can you apply a fix.

You should understand that for a language such as C++, you can throw "stuff" at a problem without any investigation as to why the problem occurs, with that "stuff" seeming to fix the problem. All that you really did do was possibly mask the problem --the problem still exists. Using "new" may have just masked the real reason why the problem occurred.

Paul McKenzie

At some point my program was running fine with no memory leaks and doing what I wanted. Then I decided it would be cleaner to create a rather complex class as static. I declared it the .h file of the top class structure AR2_Message_processordlg.h (I am at home and the exact name is not correct.) It was declared as
[CODE] C_Message_Processsor m_Message_Processor [CODE]
I run my code frequently and with few changes. It immediatley gave me a stack overflow. So I changed the declaration back to:

 C_Message_Processor mp_Message_Processor

and in the OnInitDialog I have:

 mp_Message_Processor = new C_Message_Processor

along with other checks to see that it really is there.
The stack overflow immediately stopped.
So where else should I look for this problem?

Edit: Again, I cannot cut/paste from my work computer and am at home, please excuse any typos and inconsistancies with earlier posts.

[GCDEF]

You use the debugger. Stack overflow usually comes from uncontrolled recursion, or trying to allocate a huge block of memory on the stack. Does your class contain a large array or other chunk of memory like that?

[bkelly]

You use the debugger. Stack overflow usually comes from uncontrolled recursion, or trying to allocate a huge block of memory on the stack. Does your class contain a large array or other chunk of memory like that?

This application does not use any recursion. There are two large arrays that are are allocated dynamically after the program prompts for a a configuration file name and reads it. The stack overflow occurs immediately on start and before the config file read so it is not associataed with the arrays. On exit in the debugger there are no notices of memory leaks. (not definitive, but a good indicator.)

[VictorN]

The stack overflow occurs immediately on start ..

"on start" of what?
Is at a WinMain? Or CWinApp::InitInstance? Or your OnInitDialog?
Did you set breakpoints in the beginning of all of these functions? Did you debug?

[bkelly]

"on start" of what?
Is at a WinMain? Or CWinApp::InitInstance? Or your OnInitDialog?
Did you set breakpoints in the beginning of all of these functions? Did you debug?

On start of the application. From the OP: Environment: Windows XP Pro, Visual Studio 2008, MFC, C++

When I looked at the call stack, none of the modules I wrote were listed. I am not sufficiently well versed in MS internals to troubleshoot and interpert their code. (I am not claiming the problem is in their code, but the symptoms originate from within their code.) Note again, I made a change, solicted the error, reversed the change, eliminated the error. That's a a pretty good basis for concluding that my change was not well advised.
Maybe as I get better at this I will be more able to investigate this type of problem. In the mean time, I have code to write and test.