Kein MessageBox() nach PostQuitMessage()
-
Also im Destruktor meiner Fenster-Klasse rufe ich DestroyWindow() auf. Auf die daraufhin gesendete WM_DESTROY-Nachricht reagierte ich bisher eben mit PostQuitMessage(0).
Macht das PostQuitMessage() denn wirklich nicht mehr, als GetMessage() dazu zu bewegen, aus der Hauptschleife herauszuspringen, damit das Programm endet? In diesem Fall wäre es ja kein Problem, statt des PostQuitMessage()-Aufrufs einfach ein Flag zu setzen und abhängig von diesem dann aus der Hauptschleife zu springen. Ich dachte nur immer, dass Fenster würde nur durch PostQuitMessage() korrekt geschlossen werden. Wenn es aber wirklich nur darauf ankommt, das Programm durch ein return zum Ende zu bringen und das Fenster dadurch ordnungsgemäß automatisch mitgeschlossen wird, wäre ja alles in Ordnung.
-
Wenn WM_QUIT nicht gesendet würde, würde die Schleife ja niemals beendet werden. Ich mache es normalerweise immer so, dass ich bei WM_QUERYENDSESSION und WM_CLOSE prüfe, ob das Fenster geschlossen werden kann (dirty-Flag) und rufe anschließend DestroyWindow auf. Anschließend kommt das WM_DESTROY, wo PostQuitMessage die Schleife beendet. Danach kommen alle Aufräumarbeiten.
-
Naja, durch Setzen eines Flags bei WM_DESTROY könnte die Schleife wie beschrieben auch anders als durch klassisches Prüfen des Rückgabewerts von GetMessage() beendet werden. Meine Frage war ja daher, ob dies "zulässig" wäre oder ob der Aufruf von PostQuitMessage(0) noch andere wichtige Sachen erledigt und somit nicht zu ersetzen ist.
Da ich mein Fenster in eine Klasse gekapselt habe wird im Falle einer Exception ja erst deren Destruktor aufgerufen (welcher dann eben DestroyWindow() und somit auch PostQuitMessage() aufruft) und dann erst in den catch-Block gesprungen, in welchem ich aber gerne meine MessageBox mit dem Fehler ausgeben würde.
-
Bist du denn gerade bei deiner 3D-Anwendung? Bei so etwas ist es generell geschickter, sich ein Logging-System auf HTML-Basis aufzubauen. Warum HTML? So kannst du den Browser geöffnet halten, die Anwendung starten und bei Problemen sofort mit F5 die Ansicht im Browser aktualisieren.
Ich kenne keinen anderen Grund für PostQuitMessage, du kannst normalerweise auch WM_QUIT direkt schicken, wobei der WPARAM dann der Exit-Code ist.
-
Ein HTML-Log ist sicherlich etwas Schönes zur Fehlerprüfung während der Entwicklung, aber um dem Benutzer etwas mitzuteilen ist eine MessageBox meiner Meinung nach doch die bessere bzw. direktere Lösung.
Vielleicht kann ja Martin Richter noch einmal bestätigen, dass PostQuitMessage() nicht notwendig ist, sondern die von mir beschriebene Methode mit dem Flag ebenfalls völlig korrekt ist
-
MSDN schreibt
The PostQuitMessage function posts a WM_QUIT message to the thread's message queue and returns immediately; the function simply indicates to the system that the thread is requesting to quit at some time in the future.
Also PostMessage(hwnd, WM_QUIT, 0, 0); ist das Gleiche.
-
Das scheint leider nicht der Fall zu sein. Die MSDN sagt außerdem:
Do not post the WM_QUIT message using the PostMessage function; use PostQuitMessage.
-
Okay, gut zu wissen. Ich brauchte es bisher aber auch noch nicht.
-
Siehe auch:
http://blogs.msdn.com/b/oldnewthing/archive/2005/11/04/489028.aspx
http://blogs.msdn.com/b/oldnewthing/archive/2005/02/22/378018.aspx
-
Aus dem zweiten Link lese ich heraus, dass zwischen einem Quit-Flag und PostQuitMessage() somit doch ein feiner Unterschied besteht. Allerdings ist dort von "layers of modality" die Rede. In meiner Anwendung habe ich jedoch nur ein einziges normales Hauptfenster. Wäre es in diesem Fall also möglicherweise doch in Ordnung, bei WM_DESTROY ein Flag zu setzen, dass dann dafür sorgt, dass die Hauptschleife beendet wird, anstatt PostQuitMessage() aufzurufen und dann den Rückgabewert von GetMessage() bzw. PeekMessage() auszuwerten?