Behauptungsfehler

Question

In vc++6.0 MFC-Anwendungsprojekt, werde ich nicht die kompilieren Fehler, aber wenn ich das Projekt ausführen, werde ich den Fehler erhalten

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)

welcher Fehler es ist und warum diese Art von Fehler auftritt, wie man diesen Fehler zu beheben, plz helfen jeder Körper,

Answer 1

Wahrscheinlich finden Sie eine Assertion in winocc.cpp in Zeile 345. Schauen Sie sich die Quelldatei an, um zu sehen, worauf sie prüft (was Sie nicht tun sollten), und hören Sie dann auf, es zu tun :-)

Wenn Sie den Quellcode nicht haben, dann müssen Sie ihn auch nicht haben:

• sich mit dem Verfasser in Verbindung zu setzen und herauszufinden, wie die Behauptung lautet; oder
• Lesen Sie die API-Dokumente, um zu sehen, ob Sie etwas falsch machen.

Eine Behauptung ist eine Laufzeit Prüfung, mit der der Programmierer sicherstellt, dass die Regeln eingehalten oder unerwartete Situationen abgefangen werden, bevor ein wirklicher Schaden entsteht. Dinge wie eine doppelt verknüpfte Liste, die beschädigt wird (z.B. etwas wie assert (x->next->prev != x), das ein Problem feststellt, wenn der vorherige Knoten von Knoten A keinen Knoten A als nächsten Knoten hat).

Etwa so:

Assert (p1 == NULL);

(in meiner mythischen Sprache, für den Fall, dass ich die C-Syntax falsch habe) am Anfang einer Funktion wird eine Behauptung auslösen, wenn p1 gleich NULL ist.

Eine Websuche ergibt in Zeile 345 folgendes (siehe aquí ) :

ASSERT(m_pCtrlSite != NULL); // kein OLE-Steuerelement (zumindest noch nicht).

und es scheint ein Problem mit der Tatsache zu sein, dass Sie versuchen, ein lizenziertes ActiveX-Steuerelement dynamisch zu erstellen. Dieser Link enthält auch die KB-Nummer Q151804, die besagt, dass das Problem von MS entwickelt wurde (was bedeutet, dass MS es wahrscheinlich nicht behoben hat) - Sie müssen das Steuerelement mit einer gültigen Lizenzzeichenfolge erstellen.

Ein weiterer Kommentar, den ich gefunden habe, besagt:

Es reicht nicht aus, nur eine Instanz des ActiveX-Steuerelements zu erstellen. Ein ActiveX-Steuerelement muss ordnungsgemäß gehostet werden, bevor es verwendet werden kann. Das ist bei Ihnen nicht der Fall. Sie müssen es z. B. in ein Dialogfeld einfügen und eine Instanz dieses Dialogfelds erstellen.

Ohne den Rest Ihres Codes zu sehen, ist es schwer zu sagen, ob dies Ihr spezielles Problem ist, aber wenn su Zeile 345 ist diejenige, die ich denke, dass es ist, das macht Sinn - es beschwert sich, dass die Steuerseite NULL ist (d.h., das Steuerelement ist nicht gehostet).

Ein letzter Punkt, auf den Sie achten sollten:

Wenn Ihr ActiveX-Steuerelement est in einem Dialog, versuchen Sie, etwas mit dem Steuerelement zu tun vor rufen Sie die Dialogfunktion DoModal() ?

Das Steuerelement wird erst initialisiert, nachdem Sie die DoModal() Sie können also erst dann mit der Steuerung spielen, wenn dies geschehen ist. Sie sollten dies in den Dialogen tun OnInitDialog() - zu diesem Zeitpunkt sollte das Steuerelement vollständig initialisiert sein und Sie können damit tun, was Sie wollen.

Wenn Sie versuchen, Parameter aus dem Konstruktor des Dialogs zu verwenden, um das Steuerelement zu manipulieren, müssen Sie sie irgendwo in der Dialog und übertragen sie auf die Steuerung in OnInitDialog() .

Diese Informationen wurden hauptsächlich von folgenden Personen gesammelt aquí .

Answer 2

Ein "assert(...)" soll Ihnen helfen, Fehler in Ihrem C++-Programm zu finden.

Normalerweise werden bei einem Produktions-Build alle Assertions "herauskompiliert", so dass sie nicht zum Absturz der Anwendung führen.

Answer 3

Assertions werden verwendet, um Vorbedingungen/Nachbedingungen und Zwischenergebnisse im Code zur Laufzeit zu überprüfen.

Wahrscheinlich haben Sie eine Funktion/Methode aufgerufen, ohne alle Vorbedingungen zu beachten, und dies wurde zur Laufzeit erkannt.

In VC werden Assertions in den Binärdateien auf dem Debug-Target eingeführt, nicht aber auf dem Release-Target.

Answer 4

Wenn es sich nicht um eine Dll handelt, die Sie kontrollieren (manchmal hinterlässt ein Hersteller eine Assert in einer Debug-Bibliothek), können Sie die Disassemblierung zeigen und die Speicherposition der Assert (wo sie abbricht) von 3 auf 90 ändern. Dadurch wird Ihr __asm int 3 zu einem __noop. Das ist gut, um einen Interrupt zu löschen, den man loswerden kann - zumindest für diese Debugging-Sitzung :)