manuelles Beenden des Programms

Pellaeon

MSDN schrieb:

Do not post the WM_QUIT message using the PostMessage function; use PostQuitMessage.

ok, aber nur wenn man PostMessage nimmt. Hir wird ja SendMessage verwendet. Im übrigen hat man wie schon gesagt bei der Verwendung von PostQuitMessage wahnsinnig viele Speicherlecks

AndRo67

OnAppExit() funzt auch, ist von CWinApp abgeleitet und auch in der MSDN zu finden.

Und wo ist das zu finden? Weder auf meiner CD-MSDN (ist schon uralt) noch online (Link) kann ich das finden...

Pellaeon

Hm wenn ich raten soll, würd ich sagen das WM_QUIT die Anwendung schließt, ohne den Fenstern die Möglichkeit zu geben ihre Ressourcen freizugeben. Weil für WM_CLOSE gibts ja einen Nachrichtenhandler in CWnd.

Würd mich aber auch mal genauer interessieren, falls da jemand genaueere Kentnisse zu hat.

Pellaeon

hm jo WM_CLOSE ruft irgendwann WM_QUIT. Zumindest muss man das bei reiner WinAPI machen, aslo wirds auch in der MFC irgendwie verankert sein.

Folgendes hab ich in meiner MSDN-CD-Version gefunden:

ID_APP_EXIT Exit the application.
CWinApp::OnAppExit handles this command by sending a WM_CLOSE message to the application's main window. The standard shutting down of the application (prompting for dirty files and so on) is handled by the CFrameWnd implementation.

Customization of this command handler is not recommended. Overriding CWinApp::SaveAllModified or the CFrameWnd closing logic is recommended.

If you choose to implement this command, we recommend you use this command ID.

Somit müsste der Ansatz mit WM_CLOSE der richtige sein, da das Anwendungsgerüst alles dann selbst erledigt.

pZy

Im übrigen hat man wie schon gesagt bei der Verwendung von PostQuitMessage wahnsinnig viele Speicherlecks

Kannst du das mal erklären? Was meinst du mit "hat man Speicherlecks?".

PostQuitMessage postet einfach eine WM_QUIT an den aktuellen Thread. Der kann dann selber schauen, wie er damit umgeht.

Wenn dus hart haben willst, geht auch ::ExitInstance(). Schön ist es nicht, evtl. wurden vorher nicht alle Ressourcen freigegeben. Weil die Applikation aber ziemlich sicher beendet wird macht das ja nichts, Windows kümmert sich dann darum.

In einer MFC Dialoganwendung wäre EndDialog() ok.

WM_CHEERS

Warning: destroying CSingleDocTemplate with live document.
Detected memory leaks!
Dumping objects ->
{270} normal block at 0x002F6658, 23 bytes long.
Data: < 2| > D8 9C 32 7C 06 00 00 00 06 00 00 00 01 00 00 00
{229} normal block at 0x002F5370, 26 bytes long.
Data: < 2| > D8 9C 32 7C 09 00 00 00 09 00 00 00 01 00 00 00
array_p.cpp(112) : {223} normal block at 0x002F6050, 20 bytes long.
Data: < $R/ > 00 00 00 00 24 52 2F 00 00 00 00 00 CD CD CD CD
array_p.cpp(69) : {222} normal block at 0x002F6010, 4 bytes long.
Data: < > 00 00 00 00
winfrm2.cpp(62) : {221} client block at 0x002F5F10, subtype c0, 192 bytes long.
a CDockBar object at $002F5F10, 192 bytes long
array_p.cpp(69) : {220} normal block at 0x002F5ED0, 4 bytes long.
Data: < > 00 00 00 00
winfrm2.cpp(62) : {219} client block at 0x002F5DD0, subtype c0, 192 bytes long.
a CDockBar object at $002F5DD0, 192 bytes long
array_p.cpp(69) : {218} normal block at 0x002F5D90, 4 bytes long.
Data: < > 00 00 00 00
winfrm2.cpp(62) : {217} client block at 0x002F5C90, subtype c0, 192 bytes long.
a CDockBar object at $002F5C90, 192 bytes long
winfrm2.cpp(62) : {215} client block at 0x002F5B90, subtype c0, 192 bytes long.
a CDockBar object at $002F5B90, 192 bytes long
bardock.cpp(735) : {214} normal block at 0x002F5968, 176 bytes long.
Data: < } | > C4 7D 14 7C CD CD CD CD CD CD CD CD CD CD CD CD
{213} normal block at 0x002F5B40, 19 bytes long.
Data: < 2| > D8 9C 32 7C 02 00 00 00 02 00 00 00 01 00 00 00
{212} normal block at 0x002F5AF0, 20 bytes long.
Data: < 2| > D8 9C 32 7C 03 00 00 00 03 00 00 00 01 00 00 00
{211} normal block at 0x002F5AA0, 19 bytes long.
Data: < 2| > D8 9C 32 7C 02 00 00 00 02 00 00 00 01 00 00 00
{207} normal block at 0x002F5840, 80 bytes long.
Data: < @ > 00 00 00 00 40 01 00 00 00 01 00 08 00 00 00 00
plex.cpp(32) : {204} normal block at 0x002F5788, 124 bytes long.
Data: < W/ $R/ > 00 00 00 00 98 57 2F 00 00 00 00 00 24 52 2F 00
plex.cpp(32) : {203} normal block at 0x002F56D0, 124 bytes long.
Data: < 8V/ > 00 00 00 00 00 00 00 00 00 00 00 00 38 56 2F 00
d:\programmierung\temp\testview.cpp(20) : {202} client block at 0x002F5638, subtype c0, 88 bytes long.
a CWickelView object at $002F5638, 88 bytes long
{198} normal block at 0x002F5410, 23 bytes long.
Data: < 2| > D8 9C 32 7C 06 00 00 00 06 00 00 00 01 00 00 00
d:\programmierung\temp\mainfrm.cpp(16) : {195} client block at 0x002F50B8, subtype c0, 548 bytes long.
a CMainFrame object at $002F50B8, 548 bytes long
{186} normal block at 0x002F5058, 34 bytes long.
Data: < 2| > D8 9C 32 7C 11 00 00 00 11 00 00 00 01 00 00 00
{114} normal block at 0x002F4FE8, 45 bytes long.
Data: < 2| > D8 9C 32 7C 0E 00 00 00 1C 00 00 00 01 00 00 00
{111} normal block at 0x002F2EE0, 28 bytes long.
Data: < 2| > D8 9C 32 7C 0B 00 00 00 0B 00 00 00 01 00 00 00
{110} normal block at 0x002F29D8, 20 bytes long.
Data: < 2| > D8 9C 32 7C 03 00 00 00 03 00 00 00 01 00 00 00
d:\programmierung\temp\testdoc.cpp(54) : {109} client block at 0x002F2DA8, subtype c0, 248 bytes long.
a CTestDoc object at $002F2DA8, 248 bytes long
Object dump complete.

Soviel erst mal zu den Speicherlecks. Warum das so ist: keine Ahnung.... mach das ja noch nicht so lange. Offensichtlich wird da nich alles freigegeben. Wenn man SendMessage mit WM_CLOSE macht ist das nicht so.
EndDialog schließt doch ein Dialogfenster aus der Klasse CDialog soweit ich weiß. Das würde beim Mainframe nicht ganz funktionieren.

Pellaeon

wie schon oben angedeutet: WM_CLOSE ruft WM_QUIT auf, tut aber wohl vorher noch ein paar andere Sachen machen, wie z.B. anscheindend ads Fenster freigeben. Wers genau wissen will: mit dem Debugger durchgehen

Das WM_CLOSE wird in der Regel an alle Clients durchgereicht, sprich alle Dokumente werden ordnungsgemäß geschlossen. WM_QUIT dagegen ist eher mit dem bereits erwähnet ExitInstance zu vergleichen.

Zumal bei WM_CLOSE das Standardverfahren für ungesicherte Dokumente etc. durchlaufen wird. Sollte aber in diesem speziellen Fall nicht von Belang sein. Wenn man bereits in InitInstance die Entscheidung trifft, die Applikation garnicht weiter auszuführen, reicht auch ein return FALSE;

Speicherleaks sind an dieser Stelle eh irrelevant, wenn die App abgeschossen wird. Und was die Dokumente angeht, was soll da schon groß drinne stehen, wenn man noch in InitInstance steckt.