maremortis
asked on
vc++ debug assertion error
help :\
Debug Assertion Failed!
Program: ...\DAPP\DEBUG\DAPP.EXE
File: appcore.cpp
Line: 85
&
Program: ...\DAPP\DEBUG\DAPP.EXE
File: appcore.cpp
Line: 92
any thoughts?
-mare mortis
(oops, didn't mean to post this here, still need help though)
Debug Assertion Failed!
Program: ...\DAPP\DEBUG\DAPP.EXE
File: appcore.cpp
Line: 85
&
Program: ...\DAPP\DEBUG\DAPP.EXE
File: appcore.cpp
Line: 92
any thoughts?
-mare mortis
(oops, didn't mean to post this here, still need help though)
ASKER CERTIFIED SOLUTION
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
Sorry to say that, but the fault is most likely not on the part of the appwizard's code. The asserts are there to ensure, that you are using the framework properly. If you get a debug-assertion, you are making a mistake, not the framework that's telling you about it. Let's assume you have a line of code that reads like this (taken from CWnd::Attach):
ASSERT( m_hWnd == NULL );
it makes sure that you can only attach a 'fresh', i.e. unused CWnd object to an existing window. The MFC is an extremely complex framework. To make it safe it is plastered with assertions to ensure proper use.
To illustrate the use of ASSERT here is a more basic example of how it works. Let's say you are writing a function that operates on a CWnd object:
void SafeShowWindow( CWnd* pWnd ) {
// ensure that you do not accidentally pass a NULL-pointer
ASSERT( pWnd != NULL );
pWnd->ShowWindow( SW_SHOW );
}
If you now attempt to call SafeShowWindow( NULL ); you will get a dialog during a debug session stating the file and line number where something went wrong. You can now go the the call stack window and find out where it was called from and fix the problem, before the application just crashes when compiled in release mode.
One more note: assertions will only be compiled in debug builds -- they do not exist in release builds anymore and therefore don't present a performance issue. They are of great help during debugging, especially the MFC-ASSERT macro that gives you a lot more information (especially file name and line number) than the C Run-Time Library's assert-function. Use it whenever you want to be rather safe than sorry. And don't get mad at the appwizard when it tells you that your application has logical errors.
I hope that made it a bit more clear, what exactly the problem is you are facing.
.f
ASSERT( m_hWnd == NULL );
it makes sure that you can only attach a 'fresh', i.e. unused CWnd object to an existing window. The MFC is an extremely complex framework. To make it safe it is plastered with assertions to ensure proper use.
To illustrate the use of ASSERT here is a more basic example of how it works. Let's say you are writing a function that operates on a CWnd object:
void SafeShowWindow( CWnd* pWnd ) {
// ensure that you do not accidentally pass a NULL-pointer
ASSERT( pWnd != NULL );
pWnd->ShowWindow( SW_SHOW );
}
If you now attempt to call SafeShowWindow( NULL ); you will get a dialog during a debug session stating the file and line number where something went wrong. You can now go the the call stack window and find out where it was called from and fix the problem, before the application just crashes when compiled in release mode.
One more note: assertions will only be compiled in debug builds -- they do not exist in release builds anymore and therefore don't present a performance issue. They are of great help during debugging, especially the MFC-ASSERT macro that gives you a lot more information (especially file name and line number) than the C Run-Time Library's assert-function. Use it whenever you want to be rather safe than sorry. And don't get mad at the appwizard when it tells you that your application has logical errors.
I hope that made it a bit more clear, what exactly the problem is you are facing.
.f
ASKER
-mare mortis