Want to protect your cyber security and still get fast solutions? Ask a secure question today.Go Premium

x
?
Solved

vc++ debug assertion error

Posted on 2003-03-21
3
Medium Priority
?
1,175 Views
Last Modified: 2012-06-21
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)
0
Comment
Question by:maremortis
  • 2
3 Comments
 
LVL 8

Accepted Solution

by:
fl0yd earned 150 total points
ID: 8184621
Just what it says: An assumption that was made wasn't met. Check lines 85 and 92 of appcore.cpp and you have all the information you need to fix the problem.

.f
0
 

Author Comment

by:maremortis
ID: 8186462
The cause wasn't in any of my code..it was something the mfc dll appwizard (which i won't use again) was throwing in there, points for being the only one to try and help me :)

-mare mortis
0
 
LVL 8

Expert Comment

by:fl0yd
ID: 8187936
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
0

Featured Post

Industry Leaders: We Want Your Opinion!

We value your feedback.

Take our survey and automatically be enter to win anyone of the following:
Yeti Cooler, Amazon eGift Card, and Movie eGift Card!

Question has a verified solution.

If you are experiencing a similar issue, please ask a related question

In this post we will learn different types of Android Layout and some basics of an Android App.
This article will show how Aten was able to supply easy management and control for Artear's video walls and wide range display configurations of their newsroom.
In this fifth video of the Xpdf series, we discuss and demonstrate the PDFdetach utility, which is able to list and, more importantly, extract attachments that are embedded in PDF files. It does this via a command line interface, making it suitable …
Screencast - Getting to Know the Pipeline

580 members asked questions and received personalized solutions in the past 7 days.

Join the community of 500,000 technology professionals and ask your questions.

Join & Ask a Question