Programm beendet sich nicht

jokey2

jokey2

Erfahrenes Mitglied
Unter bestimmten Umständen beendet sich meine Applikation (VC++6, MFC, SDI) nicht.
Wenn ich das Programm nur starte und dann gleich wieder beende, dann schließt sich zwar das Fenster, aber das Programm bleibt in der Message-Loop in PumpMessage() beim Aufruf von GetMessage (Assembler: call dword ptr [__imp__GetMessageA@16 (006f9e80)]) stehen.
Wenn ich aber ein Dokument lade oder auch nur ein neues Dokument explizit anlege (Datei->Neu), dann kann ich das Programm korrekt beenden.
Es scheint so, als passierte irgendetwas in der Nachrichtenverarbeitung, wenn ich ein Dokument lade, was vorher nicht passiert, aber nötig ist. Nur komme ich leider nicht darauf, was das sein könnte.
Ich kann nur hoffen, daß von Euch jemand einen Tip hat, woran das liegen könnte und wie ich das Problem beheben kann.

Schonmal ein hoffnungsvolles Danke,

jokey
 
Machst du in dem Document irgendetwas Besonderes? Evtl. könnte mal alles mögliche ausklammern schon helfen.

Kannst du feststellen, bei welcher Nachricht der gerade hängt? Hängt das innerhalb von GetMessage oder in der MFC-Haupthook-Proc (samt PreTranslateMessage)?
 
Es hängt nicht mit dem Dokument zusammen. Ich hatte schon den kompletten Inhalt der OnNewDocument-Funktion auskommentiert, so daß da gar nichts mehr passierte, das verhalten blieb gleich.
Das Fenster ist dreifach geteilt (etwa wie Outlook). Links oben ist ein TreeView, das schon beim Start 2 Einträge hat, da 2 Bäume darin dargestellt werden. Die Wurzelelemente dieser Bäume sind also schon da, der obere davon ist selektiert. Wenn ich jetzt gleich nach dem Start den anderen Eintrag selektiere, dann beendet das Programm auch korrekt. Basierend darauf habe ich jetzt einen Workaround, indem ich im OnInitialUpdate nach dem selektieren des ersten TreeView-Eintrages den zweiten Eintrag selektiere, danach wieder den ersten. Auch das hat den Effekt, das sich das Programm korrekt beendet, auch wenn kein Dokument geladen oder ein Neues angelegt wurde.
So geht es zwar, schön ist es aber nicht. Ich wüßte schon gerne, woran es da hängt.

Es bleibt in der GetMessage-Funktion hängen, und zwar scheinbar beim Rücksprung (auf der ret-Anweisung im Assemblercode). Kannst Du mir sagen, in welchem Register die Rücksprungadresse steht? Ich hab's nämlich vergessen :-(

Die Message ist 0xc0b6 mit WParam = 1, lParam = 0, hWnd = 0. Leider habe ich die zur Nummer gehörige Nachricht nicht gefunden.

Sagt Dir das ganze etwas?
 
Zuletzt bearbeitet:
Ich hab noch rausgefunden, daß die Message eine registrierte Message (RegisterWindowsMessage(...)) sein muß, da die von 0xc000 bis 0xFFFF gehen.
Leider finde ich weder raus, was sie bewirken soll, noch hilft es mir sonst irgendwie weiter. Auf jeden Fall kommt diese Message auch während des Programmlaufes, und da läuft alles gut.
 
Also der Rückgabewert sollte sich üblicherweise in EAX befinden.

Hast du einen TVN_SELCHANGE-Handler? Mir ist da neulich erst aufgefallen, dass beim Zerstören eines TreeControls manchmal die Selektion geändert wird und dann zu einem sehr ungünstigen Zeitpunkt während des Zerstörens dieser Handler aufgerufen wird.
 
Ich meinte nicht den Rückgabewert sondern die Rücksprungadresse aus Subroutinen, an die beim Aufruf des ret-Befehls gesprungen wird.

Einen TVN_SELCHANGE-Handler habe ich, auch einen TVN_SELCHANGING-Handlet, aber keiner der beiden wird beim Beenden angesprungen.

Ich bin ratlos, aber schonmal Danke für Deine Bemühungen.
 
In so einem verzweifelten Fall würde ich mal eine WindowProc in deinen Tree bzw. dessen Parent mit einsetzen und ALLE Nachrichten rausloggen. Dann siehst du, welche am Schluss hängen bleibt.

Sorry, bei der Rücksprungadresse bin ich mir nicht sicher.
 
Danke für die Hilfe. Das werde ich mal tun, kann aber etwas dauern, da ich jetzt erstmal im Urlaub bin. ;-)
 
Ja wie? Bei Programmierern ist der Urlaub doch für freizügiges, nicht von der Arbeit unterbrochenes Programmieren! :D
 
Sag das mal meiner Frau! ;-)
Ich hätte ja genug Sachen, die ich gerne mal programmieren würde, aber ich darf den Rechner leider nicht mitnehmen.
 
Um antworten zu können musst du eingeloggt sein.

Neue Beiträge

Zurück