Event für Programmterminierung?

Ist es möglich irgendwie einen Event abzufangen wenn der Benutzer über STRG+ALT+ENTF mein Programm schließt damit ich noch ein paar Dateien des Programms aufräumen könnte? Ich verwende die WinApi.

Vielen Dank!!!

BorisDieKlinge

WM_QUIT abfangen!

Wenn du im Taskmanager ein Process/task killst, versucht windows zu allererst das Programm normal zu beenden, als wird ein "WM_QUIT" gefeuert! Wenn das Programm aber nich reagiert, wird es hardcore vom Spreicher gelöscht;)

Wenn du das Programm normal beendest, bzw. "Alt +F4" drückst, wird auch die "WM_QUIT" Message gesendet.

d.h. wenn der User Ctrl+alt+entf dr+ück, bekommt dein Programm eine "WM_QUIT" message;)

bevor die child-windows zerstört werden WM_DESTROY.
letzte chance ist nachdem die child-windows zerstört wurden. dann kommt die zerstörung des nonclient bereichs (aka hardcore-zerstörung ;)) WM_NCDESTROY.

C++ Forumbot

Dieser Thread wurde von Moderator/in HumeSikkins aus dem Forum C++ in das Forum WinAPI verschoben.

Im Zweifelsfall bitte auch folgende Hinweise beachten:
C/C++ Forum :: FAQ - Sonstiges :: Wohin mit meiner Frage?

Dieses Posting wurde automatisch erzeugt.

Vielen Dank! Und wie könnte ich erkennen dass ein Benutzer das Programm schließt indem er mit der rechten Maustaste auf das Programm in der Taskleiste klickt -> close? Es scheint kein Event gesendet zu werden...

Mmacher

Nomen est omen -> WM_CLOSE

Benutzt man die Schaltfläche "Task beenden", wird das Programm mittels WM_CLOSE geschlossen.
Benutzt man die Schaltfläche "Prozess beenden", wird der Prozess mit TerminateProcess beendet und dann gibt es keine Nachrichten mehr.

wenn der Benutzer über STRG+ALT+ENTF mein Programm schließt damit ich noch ein paar Dateien des Programms aufräumen könnte

Nur ein schlechter Programmierer sollte es nötig haben, den User davon abzuhalten, das Programm unvorhergesehen zu terminieren...
Das geht dann schon fast in den Bereich von Malware, was ist wenn der Computer abstürzt, dann kannst du auch nicht mehr aufräumen

C-Chris

Nur ein schlechter Programmierer sollte es nötig haben, den User davon abzuhalten, das Programm unvorhergesehen zu terminieren...

Installationen bei denen in die Registry geschrieben wird.
Es gibt viele Gründe den Benutzer zu einem Nicht-Abbruch zu zwingen.
Bei Spielen während der Spielstandspeicherung. Bei vielen Zeichendestrukten(wenn Zeichnungen entfernt werden).
Ja in Windows ist das meist recht gut geregelt es kann allerdings in manchen Fällen schon zu Bugs kommen.

C-Chris

Programmer123456 schrieb:

Ist es möglich irgendwie einen Event abzufangen wenn der Benutzer über STRG+ALT+ENTF mein Programm schließt damit ich noch ein paar Dateien des Programms aufräumen könnte? Ich verwende die WinApi.

Vielen Dank!!!

Eigentlich heisen die garnicht Events sonderen Botschaften. Kommst von .NET?

CodeFinder

C-Chris schrieb:

Eigentlich heisen die garnicht Events sonderen Botschaften. Kommst von .NET?

Naja, eigentlich eher Nachrichten .

hustbaer

C-Chris schrieb:

Nur ein schlechter Programmierer sollte es nötig haben, den User davon abzuhalten, das Programm unvorhergesehen zu terminieren...

Installationen bei denen in die Registry geschrieben wird.
Es gibt viele Gründe den Benutzer zu einem Nicht-Abbruch zu zwingen.
Bei Spielen während der Spielstandspeicherung.

Ich sehe keinen Grund das Beenden des Programmes hier zu verhindern.
Einen Installer kann man so schreiben dass er wenn er "abgewürgt" wurde, und dann neu gestartet wird, weiss, was er tun muss um die Installation fortzusetzen oder rückgängig zu machen.
Beim Spielstand Speichern kann man (und sollte man) die neue Datei erstmal unter einem anderen Namen speichern und nicht über die alte drüberschreiben. Wenn das geschehen ist kann man die neue Datei über die alte "drüber-moven" (was unter jedem guten Dateisystem eine Atomare Aktion sein sollte, vorausgesetzt natürlich beide liegen auf dem selben Datenträger/der selben Partition). Wenn das Spiel das nächste mal läuft braucht es nur zu checken ob ein Spielstand mit einem "temporären Namen" existiert, und kann dann die Datei löschen (da sie fast sicher unvollständig ist).

Auch den Verlust von ungesicherten Daten kann man minimieren indem man seinem Programm einfach beibringt alle paar Minuten mal eine Backup-Kopie zu speichern. Hängt sich das Programm dann wirklich weg und muss per TerminateProcess o.ä. beendet werden hat man immernoch die letzte Backup-Kopie, und nicht mehr als ein paar Minuten Arbeit verloren. Dasselbe kann man bei Spielen machen, einfach alle paar Minuten ein automatisches Quick-Save machen, damit der Spieler im Fall des Falles nicht eine ganze Gaming-Session verloren hat, sondern dort wieder einsteigen kann wo er ein paar Minuten vorher war.

Der nette Seiteneffekt von solchen Techniken: sie greifen nicht nur wenn das Programm vom User beendet wurde, sondern auch wenn das Programm sich auf Grund eines Fehlers selbst torpediert und versenkt hat.

Zu verhindern dass ein Programm (Prozess) vom User "abgeschossen" werden kann beschwört dagegen IMO viel mehr Probleme herauf als man damit lösen kann.

Bei vielen Zeichendestrukten(wenn Zeichnungen entfernt werden).

Äh. Was zum Geier meinst du damit?

Desweiteren sollte es dem Benutzer bewusst sein, dass es zu einem eventuellen Datenverlust oder anderen Problemen kommt, wenn er ein Programm mit Gewalt beendet. Wenn ich mein Auto vor eine Mauer setze anstatt die Bremse zu benutzen, muss ich auch damit rechnen, das was kaputt geht.

C-Chris

Luckie1 schrieb:

Desweiteren sollte es dem Benutzer bewusst sein, dass es zu einem eventuellen Datenverlust oder anderen Problemen kommt, wenn er ein Programm mit Gewalt beendet. Wenn ich mein Auto vor eine Mauer setze anstatt die Bremse zu benutzen, muss ich auch damit rechnen, das was kaputt geht.

Ändert nichts daran das der Benutzer es trotzdem macht.

C-Chris

hustbaer schrieb:

C-Chris schrieb:

Nur ein schlechter Programmierer sollte es nötig haben, den User davon abzuhalten, das Programm unvorhergesehen zu terminieren...

Installationen bei denen in die Registry geschrieben wird.
Es gibt viele Gründe den Benutzer zu einem Nicht-Abbruch zu zwingen.
Bei Spielen während der Spielstandspeicherung.

Ich sehe keinen Grund das Beenden des Programmes hier zu verhindern.
Einen Installer kann man so schreiben dass er wenn er "abgewürgt" wurde, und dann neu gestartet wird, weiss, was er tun muss um die Installation fortzusetzen oder rückgängig zu machen.
Beim Spielstand Speichern kann man (und sollte man) die neue Datei erstmal unter einem anderen Namen speichern und nicht über die alte drüberschreiben. Wenn das geschehen ist kann man die neue Datei über die alte "drüber-moven" (was unter jedem guten Dateisystem eine Atomare Aktion sein sollte, vorausgesetzt natürlich beide liegen auf dem selben Datenträger/der selben Partition). Wenn das Spiel das nächste mal läuft braucht es nur zu checken ob ein Spielstand mit einem "temporären Namen" existiert, und kann dann die Datei löschen (da sie fast sicher unvollständig ist).

Auch den Verlust von ungesicherten Daten kann man minimieren indem man seinem Programm einfach beibringt alle paar Minuten mal eine Backup-Kopie zu speichern. Hängt sich das Programm dann wirklich weg und muss per TerminateProcess o.ä. beendet werden hat man immernoch die letzte Backup-Kopie, und nicht mehr als ein paar Minuten Arbeit verloren. Dasselbe kann man bei Spielen machen, einfach alle paar Minuten ein automatisches Quick-Save machen, damit der Spieler im Fall des Falles nicht eine ganze Gaming-Session verloren hat, sondern dort wieder einsteigen kann wo er ein paar Minuten vorher war.

Der nette Seiteneffekt von solchen Techniken: sie greifen nicht nur wenn das Programm vom User beendet wurde, sondern auch wenn das Programm sich auf Grund eines Fehlers selbst torpediert und versenkt hat.

Zu verhindern dass ein Programm (Prozess) vom User "abgeschossen" werden kann beschwört dagegen IMO viel mehr Probleme herauf als man damit lösen kann.

Bei vielen Zeichendestrukten(wenn Zeichnungen entfernt werden).

Äh. Was zum Geier meinst du damit?

abgeschwächt und man kann das Programm nichtmehr beenden(Natürlich schon mit dem TM aber sonst nicht).

Zu den "Zeichendestrukten" wenn man doch mit DirectX ein Spiel macht so muss man am Schluss wieder Speicher freigeben,etc. Zum Desktop zurück,etc. Wenn das Programm aber unvorhergesehen abgebrochen wird(es gibt solche Situationen,Eltern kommen rein :-)) dann sind dann manchmal noch solche sogenannten "Pixelfehler"(sehr verräterisch) aber manche Spiel lassen sich da Zeit(s. Team Fortess 2) und deshalb sind dort dann auch keine "Pixelfehler" mehr vorhanden. In TF2 z.B. wird das manuellle Abbrechen sehr stark geblockt.
Weil es lange dauert für diese "Renderdeinitalisierungen"(k.p. Wie das heist)-

Auf jeden Fall wird in beiden Fällen der Benutzer optisch und technisch vonm Abbrechen der Anwendung aufgehalten.

mad_martin

Hm, was genau meinst du mit "Pixelfehler" und "Renderdeinitialisierung"? Was genau soll da deiner Meinung nach abgehen?

C-Chris

CodeFinder schrieb:

C-Chris schrieb:

Eigentlich heisen die garnicht Events sonderen Botschaften. Kommst von .NET?

Naja, eigentlich eher Nachrichten .

Nein Botschaften

C-Chris

mad_martin schrieb:

Hm, was genau meinst du mit "Pixelfehler" und "Renderdeinitialisierung"? Was genau soll da deiner Meinung nach abgehen?

Ja das ist der falsche Begriff aber kennst du es nicht wenn etwas auf dem Bildschirm da ist was garnicht da sein sollte. Mir fällt kein Beispiel gerade ein. Aber ich denke du weist von was ich Rede. Doch ein konkretes Beispiel habe ich wennn du dir den Unreal Engine 2 Level Editor herunterlädst und dort mit dem Texturendialog herumkreist. Wenn du es unbedingt wissen willst dann probier es und du wirst es sehen.

Unter "Renderdeinitalisierungen" verstehe ich soetwas wie den CoperativeLevel wieder auf "Normal" zurückzusetzen. Den Vertexspeicher wieder freigeben,etc.

C-Chris

C-Chris schrieb:

mad_martin schrieb:

Hm, was genau meinst du mit "Pixelfehler" und "Renderdeinitialisierung"? Was genau soll da deiner Meinung nach abgehen?

Ja das ist der falsche Begriff aber kennst du es nicht wenn etwas auf dem Bildschirm da ist was garnicht da sein sollte. Mir fällt kein Beispiel gerade ein. Aber ich denke du weist von was ich Rede. Doch ein konkretes Beispiel habe ich wennn du dir den Unreal Engine 2 Level Editor herunterlädst und dort mit dem Texturendialog herumkreist. Wenn du es unbedingt wissen willst dann probier es und du wirst es sehen.

Unter "Renderdeinitalisierungen" verstehe ich soetwas wie den CoperativeLevel wieder auf "Normal" zurückzusetzen. Den Vertexspeicher wieder freigeben,etc.

Wahrscheinlich wird das wieder jemand bezweifeln habe ich aber alles aus einem Buch und der Autor wird sich schon auskennen.

mad_martin

AFAIK räumt Windoof hinter jedem Programm her und wirft die Anwendungsdaten dieses Programmes weg (d.h. tatsächlich wird der bisher belegte Speicher nicht explizit gelöscht, sondern in der Zuordnungstabelle nur wieder auf "frei" gesetzt). Und das unabhängig davon, ob das Programm ordnungsgemäß beendet wurde oder nicht. Wenn ein Programm ordnungsgemäß beendet wird, hat es nur noch einmal die Chance, selbst aufzuräumen, d.h. nicht gespeicherte Daten auf die Platte zu schreiben o.ä.

Ich vermute mal, du meinst mit "Pixelfehler" die Überbleibsel, die manchmal bestehen bleiben. Das liegt wohl daran, dass die unterhalb des gelöschten Fensters liegenden Fenster (und sei es nur der Desktop als unterste Fläche) noch keine Aufforderung zum Neuzeichnen bekommen haben bzw. noch irgendwas im Grafikspeicher rumdümpelt.

Achja, nur weil irgendetwas in einem Buch steht, heißt das noch lange nicht, dass der Autor sich damit auskennt

C-Chris

mad_martin schrieb:

AFAIK räumt Windoof hinter jedem Programm her und wirft die Anwendungsdaten dieses Programmes weg (d.h. tatsächlich wird der bisher belegte Speicher nicht explizit gelöscht, sondern in der Zuordnungstabelle nur wieder auf "frei" gesetzt). Und das unabhängig davon, ob das Programm ordnungsgemäß beendet wurde oder nicht. Wenn ein Programm ordnungsgemäß beendet wird, hat es nur noch einmal die Chance, selbst aufzuräumen, d.h. nicht gespeicherte Daten auf die Platte zu schreiben o.ä.

Ich vermute mal, du meinst mit "Pixelfehler" die Überbleibsel, die manchmal bestehen bleiben. Das liegt wohl daran, dass die unterhalb des gelöschten Fensters liegenden Fenster (und sei es nur der Desktop als unterste Fläche) noch keine Aufforderung zum Neuzeichnen bekommen haben bzw. noch irgendwas im Grafikspeicher rumdümpelt.

Achja, nur weil irgendetwas in einem Buch steht, heißt das noch lange nicht, dass der Autor sich damit auskennt

Aber der Grafikspeicher wird eben explizit wieder freigegeben wenn das Programm regulär beendet wird. Ich will ausserdem damit sagen dass auch professionelle Spieleentwickler einem vom Beenden abhalten. Ausserdem was soll eigentlich die sinnlose Diskussion.

Noch was:
Überbleibsel vs. "Pixelfehler" da kann ich mir ja sogar noch mehr unter "Pixelfehler" vorstellen als unter "Überbleibsel".

P.S.: Der Autor hats drauf.

P.P.S.: :xmas1: