Problem mit PostQuitMessage() - Anwendung bleibt im Speicher
-
_matze schrieb:
Der 2. Parameter von GetMessage() sollte nicht das Window-Handle hWnd sein, sondern NULL
... damit GetMessage () Botschaften für sämtliche Fenster der Anwendung (Hauptfenster, Buttons, Edits,...) aus der "MessageLoop" holt.
_matze schrieb:
Diese wird aus naheliegendem Grund nicht beendet ...
... weil Du in "WM_CLOSE" das Hauptfenster zerstörst und weil Du dann 0 zurückgibst (return 0;). return 0 in "WM_CLOSE" bedeutet, dass die Anwendung nicht beendet werden soll.
_matze schrieb:
(sie bekommt die entsprechende Nachricht ja gar nicht)
Doch, hat sie. Aber weil dann das Handle des Hauptfensters ungültig ist, liefert GetMessage () -1 zurück (schwerer Fehler).
Die GetMessage-Schleife muss auch verlassen werden, wenn GetMessage () -1 zurückgibt. Du hast ein "break" vergessen.
-
merker schrieb:
return 0 in "WM_CLOSE" bedeutet, dass die Anwendung nicht beendet werden soll.
Nicht ganz korrekt, wenn man selbst die Behandlung der Message übernimmt, sollte hier 0 zurückgegeben werden. Und eine Anwendung wird auch nicht mit der Message WM_CLOSE beendet.
Return Value
If an application processes this message, it should return zero.Remarks
An application can prompt the user for confirmation, prior to destroying a window, by processing the WM_CLOSE message and calling the DestroyWindow function only if the user confirms the choice.Und da _matze hier ein DestroyWindow aufgruft, wird das Fenster auch zerstört.
@_matze
Nur frage ich mich, warum du WM_CLOSE hier extra bearbeitest - siehe ebenfalls bei Remarks:By default, the DefWindowProc function calls the DestroyWindow function to destroy the window.
-
Analog Bit schrieb:
Nicht ganz korrekt, wenn man selbst die Behandlung der Message übernimmt, sollte hier 0 zurückgegeben werden.
Und was signalisiert man dem Betriebssystem wenn man dort 0 zurückgibt ?
-
merker schrieb:
Und was signalisiert man dem Betriebssystem wenn man dort 0 zurückgibt ?
Lies doch bitte den Beitrag komplett
-
Sprich nicht in Rätseln. Warum wird denn nun _matze's Anwendung nicht korrekt beendet ?
-
merker schrieb:
Sprich nicht in Rätseln. Warum wird denn nun _matze's Anwendung nicht korrekt beendet ?
Zum Beenden der Anwendung habe ich ja kein Kommentar geschrieben, hat er ja nun auch selber herausgefunden und du ja auch schon bereits erwähnt.
Durch DestroyWindow wird das Fensterhandle ungültig. Wie soll dann bei GetMessage noch die Message WM_QUIT ausgewertet werden. Also sollte er, (wie er es zum Schluss auch getan hat) beim Parameter HWND hier NULL (siehe MSDN) einsetzten.
-
Analog Bit schrieb:
Durch DestroyWindow wird das Fensterhandle ungültig. Wie soll dann bei GetMessage noch die Message WM_QUIT ausgewertet werden.
Also sollte er, (wie er es zum Schluss auch getan hat) beim Parameter HWND hier NULL (siehe MSDN) einsetzten.So steht das in der MSDN ?
-
siehe GetMessage
Parameters
hWnd
[in] Handle to the window whose messages are to be retrieved. The window must belong to the calling thread. The NULL value has a special meaning:
NULL
GetMessage retrieves messages for any window that belongs to the calling thread and thread messages posted to the calling thread using the PostThreadMessage function.@merker
Weitere Kommentare werde ich mir jetzt sparen.
-
Moin!
@merker:
Die Behandlung von WM_CLOSE habe ich erst nachträglich eingefügt, als Lösungsansatz. Dennoch denke ich, dass der Code zwar in dem Fall überflüssig aber korrekt ist (siehe Zitat aus MSDN von Analog Bit). Bei Behandlung einer Nachricht, auch WM_CLOSE, sollte nunmal 0 zurückgegeben werden. Wie kommst du denn darauf, dass return(0) bedeutet, dass die Anwendung ncht geschlossen werden soll?? In der MSDN steht davon meines Wissens nichts. Wenn doch (kann ich mir allerdings kaum vorstellen), dann poste bitte mal einen Link.
Mit der Geschichte, dass die GetMessage()-Schleife unter Umständen nicht beendet wird, hast du allerdings Recht. Ich habe nicht bedacht, dass GetMessage() auch -1 zurückgeben kann. Da hab ich die MSDN nicht vernünftig gelesen.
@Analog Bit:
Deine Ausführungen waren korrekt. Herzlichen Dank! Die Behandlung von WM_CLOSE ist hier, wie bereits erwähnt, Unsinn und wurde erst während der Fehlersuche eingebaut, als kläglicher Versuch, den Fehler zu eliminieren
Gruß Matze
-
_matze schrieb:
Bei Behandlung einer Nachricht, auch WM_CLOSE, sollte nunmal 0 zurückgegeben werden.
Wie kommst du denn darauf, dass return(0) bedeutet, dass die Anwendung ncht geschlossen werden soll??Das Betriebssystem hat für jede WM_xxxx eine "DefWindowProc" vorgesehen.
Die wird immer dann aufgerufen, wenn die entsprechende WM_xxxx nicht selbst behandelt wird.
Mit "return 0" signalisiert man dem Betriebssystem lediglich, dass es die dafür vorgesehene "DefWindowProc" nicht aufrufen soll.
Das ist der elementare Unterschied zu "selbst behandelt".
Bei WM_PAINT z.B. gibt man "return 0" zurück, wenn man verhinden will, dass das Betriebssystem das entsprechende Control "defaultmässig" selber zeichnet.
Bei WM_CLOSE nimmt das Betriebssystem nun mal an, dass das Hauptfenster bzw. die Anwendung beendet werden soll.
Ein "return 0" bei WM_CLOSE bedeutet deshalb, dass die Anwendung / das Hauptfenster nicht geschlossen werden soll.
-
Stimmt!
Ich hab's gerade getestet. Bei Drücken der Escape-Taste wird per SendMessage() ein WM_CLOSE gesendet. Im entsprechenden Case-Zweig wird durch return(0) verhindert, dass die Funktion bis zum DefWindowProc() kommt. Irgendwie sehr logisch...
Gruß Matze