tags:

views:

365

answers:

4
+2  Q: 

Assertion Error

In vc++6.0 MFC Application Project , I will not get the compile Error , but when i run the project i will get the error

Debug Assertion Failed!
program:project.exe
File:winocc.cpp
Line:345

For information on how your program can cause an assertion
failure, see the Visual C++ documentation on asserts.

(Press Retry to debug the application)

what Error it is and why this type of error occurs, how to debug this error, plz help any body,

+5  A: 

You'll probably find there's an assertion in winocc.cpp on line 345. Have a look at that source file to see what it's checking for (what you shouldn't be doing), and then stop doing it :-)

If you don't have the source code, then you'll have to either:

  • contact whoever wrote it and find out what the assertion is; or
  • read the API docs to see if you're doing something wrong.

An assertion is a runtime check that coder use to ensure rules are being followed or unexpected situations are caught before any real damage is done. Things like a doubly linked list becoming corrupt (e.g., something like assert (x->next->prev != x), which will assert a problem if node A's previous node doesn't have node A as a next node).

Something like:

Assert (p1 == NULL);

(in my mythical language in case I have the C syntax wrong) at the start of a function will raise an assertion if p1 is equal to NULL.

A web search turns up the following at line 345 (see here):

ASSERT(m_pCtrlSite != NULL); // not an OLE control (not yet, at least).

and it looks to be a problem with the fact that you're trying to dynamically create a licensed ActiveX control. That link also contains a KB number Q151804 which says that it's by design (which means MS probably won't have fixed it) - you need to create the control with a valid license string.

One other comment that I found states:

It is not sufficient to just create an instance of ActiveX control. An ActiveX control has to be properly hosted before it can be used. Yours isn't. You need to, say, put it on a dialog and create an instance of that dialog.

Without seeing the rest of your code, it's hard to tell if this is your specific problem, but if your line 345 is the one I think it is, that makes sense - it's complaining that the control site is NULL (i.e., the control is not hosted).

One final thing to watch out for:

If your ActiveX control is in a dialog, are you trying to do something to the control before you call the dialog's DoModal()?

The control will only be initialized after you call DoModal() so you cannot play with the control until after that's happened. You should do this in the dialogs OnInitDialog() - at that point, the control should be fully initialized and you can do what you want with it.

If you're trying to use parameters from the dialogs constructor to manipulate the control, you need to store them somewhere in the dialog and transfer them to the control in OnInitDialog().

This information was gathered mostly from here.

paxdiablo
+1 for good description
Andy White
how directly i can find winocc.cpp
If you have the source, it should be in your project somewhere. See my updated answer (give me a minute or two).
paxdiablo
+1  A: 

An "assert(...)" is supposed to help you find errors in your C++ program by checking certain conditions at runtime. There is probably something not configured right in your program that is causing this failure. Like Pax said, see if you can open up winocc.cpp and look at line 345 to see what the "assert" is checking, and see if you can figure out why it's failing.

Normally, when you do a production build, you will "compile out" all of the assertions, so that they won't cause your application to crash.

Andy White
I always leave in assertions even for production code. I'd rather have them crash immediately than cause some obscure problem 100,000 CPU instructions later. Safety over speed is one of my mantras.
paxdiablo
I agree, I think compiling out assertions is kind of silly, they're obviously there for some useful reason, so why wouldn't you want to handle those errors in your production code?
Andy White
The problem is that a customer seeing an assert failure is absolutely horrible! It's a cryptic message that they should just never see. You should handle those errors in production code.. through the use of proper error handling, like through exceptions.
Tony k
A: 

Assertions are used to check preconditions/postconditions and intermediary results in the code, at runtime.

Most probably, you called a function/method without respecting all the preconditions, and this was detected at run-time.

In VC, assertions are introduced in the binaries on Debug target, and not on Release target.

Cătălin Pitiș
A: 

If it's not a dll you control (sometimes a vendor will leave an assert in a debug library), you can show the disassembly and change the memory location of the assert (where it breaks) from 3 to 90. That will change your __asm int 3 to a __noop. Good for clearing an interrupt you can get rid of -- at least for that debugging session. :)

JP Alioto
Err, are you confusing a breakpoint with an assertion?
paxdiablo
It's all an interrupt at that point.
JP Alioto