ExitWindows

H.Brill

Hallo,

Ich will mir ein Programm machen, das um eine bestimmte Uhrzeit

sich selber beendet und Windows runter fährt. Etwa so :

Code

Declare handle btn1, Edit1, Long ende, String Datum, zeit
Window 600, 400
btn1 = Create("Button", %HWnd, "Ende", 10, 10, 60, 25)
Create("Text", %HWnd, "Eingabe :", 10, 40, 70, 25)
Edit1 = Create("Edit", %HWnd, "", 80, 40, 120, 25)

ende = 0
SetTimer 5000

WhileNot ende
  Waitinput
  If Clicked(btn1)
    ende = 1
  EndIf  
  If %wmTimer
     Datum = DT("GetTime", 2, !NOW)
     zeit = Left$(Datum, 5)
     If zeit = "13:00"
        KillTimer
        ' Hier noch Daten speichern
        ExitWindows 0
        End
     EndIf
  EndIf
EndWhile

Alles anzeigen

Nun meine Frage :

Das END wird ja wahrscheinlich nicht mehr ausgeführt, da ExitWindows die Kiste schon runter fährt.

Und bei END vor ExitWindows wird ja ExitWindows nicht mehr aufgerufen.

Wird so, wie oben, mein Programm vor dem Runterfahren trotzdem sauber beendet ?

Vielleicht kennt jemand noch was besseres.

Oder ist das sowas ähnliches, wie das Henne-Ei - Problem ?

Werbepost

Hallo!

Wenn du gerade an deiner Website arbeitest oder dein aktuelles Hosting überdenkst: Wir betreiben mit NetzLiving eine Hosting-Plattform, die speziell auf Performance, Sicherheit und einfache Verwaltung ausgelegt ist.

✔️ Schnelle Ladezeiten (optimiert für WordPress, WoltLab & Co.)
✔️ Deutsche Server & DSGVO-konform
✔️ Persönlicher Support (kein 0815-Ticket-System)

Mehr erfahren

Volkmar

Das End wird schon noch erreicht. Windows fährt nicht sofort runter. Windows runterfahren:

1. Windows sendet an ein Programm eine Botschaft "Ich will jetzt Schluß machen, darf ich?" ($0011 : wm_QueryEndSession) und wartet, daß dieses Programm das erlaubt. An der Stelle wird das Programm offene Dateien speichern und dann zustimmen.

2. Der Vorgang wird für alle offenen Fenster nacheinander durchgeführt.

3. Windows sendet die Botschaft "Jetzt ist aber wirklich Schluß" ($0016 : wm_EndSession) wiederum an alle offenen Programme, die haben jetzt immer noch Zeit, sich zu beenden, weil das wieder durch alle Programme laufen muß.

4. Gibt es noch eine Wartezeit, bevor Windows nun Ernst macht und Prozesse zwangsweise abwürgt, während es selbst kontrolliert runter fährt.

Gruß Volkmar

H.Brill

Danke für die Info.

Dann ist ja alles gut.

Volkmar

Ich wurde durch den Ruf zum Essen unterbrochen. Hier noch einen Nachtrag.

Das Vorgehen kennt eigentlich jeder. Wenn ein Programm, zum Beispiel Office, noch offene Dateien hat, wird bei der Abfrage, ob Windows enden darf, immer erst der Dialog "Wollen Sie die Änderungen noch speichern" gezeigt und die Bestätigung erst dann gegeben, wenn Du drauf reagiert hast.

"Ja", und die Datei wird gespeichert und dann bestätigt
"Nein" Datei wird nicht gespeichert
"Abbrechen" sagt Windows, es darf überhaupt nicht runter fahren.

Und wenn auf das endgültige Ende hin immer noch Anwendungen weiter werkeln und die Botschaft nicht korrekt beantworten, dann gibt es eine Meldung, daß Windows auf das Ende von Prozessen wartet. Da kannst Du auch noch eingreifen und "Abbrechen" wählen, dann endet Windows nicht. Erst, wenn da innerhalb der Wartezeit von ein paar Sekunden keine Reaktion kommt, wird Windows brutal und würgt alles ab.

Nur wir als Profaner gucken da etwas in die Röhre. Profan beantwortet solche Systemmeldungen intern mit einer Standardanwort sofort. Wir können da leider innerhalb der Botschaftsverarbeitung keinen eigenen Code mal so einfach einschmuggeln. Wir können zwar die Botschaft als Usermessage selbst behandeln und auch per SetUAnswer(N1, N2) eine Antwort festlegen, aber auch die wird sofort gegeben und nicht erst, nachdem wir eigenen Code ausgeführt haben.

Gruß Volkmar

JörgG

wobei das auch egal ist, ob und wie Windowsm mit dem ProfanProgramm umgeht.

Der ProfanProgrammierer (in diesem Fall H.Brill) erledigt ja schon alle nötigen Sachen, bevor er den ExitWindows Befehl absetzt.

Danach gibt es ja nichts mehr, was sauber beendet werden muß. Und ob das "End" nun ausgeführt wird oder nicht, spielt keine Rolle, weil Windows ja runterfährt und der RAM dann eh leer ist.

Volkmar

Stimmt ja. Ich wollte nur mal beschreiben, daß Windows nicht einfach aus ist, wenn Du Herunterfahren im Startmenü wählst oder ExitWindows aufrufst. Interessant wird das erst, wenn Du noch offene Dateien mit Änderungen hast. Ansonsten ist es ganz egal, irgendwann gibt Windows einem eventuell noch laufenden Prozess keine Rechenzeit mehr und schaltet den Strom ab. Beim nächsten Hochfahren fängt ohnehin alles bei Null an. Aber bis dahin kann noch Einiges passieren, zumindest der nächste Befehl noch abgearbeitet werden.

Gruß Volkmar

H.Brill

Das war auch eigentliche der Knackpunkt dieser Sache.

Hintergrund :

Es solle ein Barcode/QRCode in einer Kantine mit einem Scanner gelesen werden, um

Sachbezüge (Essensgeld 3 € pro Tag) errechnen zu können. Egal, ob der Mitarbeiter

jetzt das Menü für 7 € oder das kleine für 4 € ißt. Da gibt es ja auch Mitarbeiter, die

plötzlich verhindert sind (z.b. außer Haus, Meeting usw.) und auch welche, die nicht

jeden Tag, sondern nur sporadisch in die Kantine essen gehen. Damit sollte dann

sicher gestellt werden, daß derjenige, der auch dort ißt, seinen Sachbezug für den Tag

bekommt und andere, die nicht essen, eben nicht.

Jetzt kann man das Küchenpersonal (da gibt es auch Cateringfirmen) nicht nötigen, sich auch

damit zu beschäftigen. Da bekämen die letzten kein Essen mehr, da die Pause vorbei ist.

Insofern hätte ich das so gedacht, daß das Küchenpersonal nur morgens vor Kantinenöffnung

den PC anschaltet. Das Programm, das ich dann auch in den Autostart lege, startet und ließt

autark ankommende Bar/QR-codes, wertet aus, ob Mitarbeiternummer schon am speziellen

Tag (!NOW) in der Liste vorhanden. Wenn ja, hat er bereits schon gegessen und hat wahrscheinlich

größeren Hunger. Das kann dann verworfen werden. Wenn man das nochmals speichern würde,

bekäme der ja 2x Zulage. Es ist aber nur einmal pro Tag vorgesehen. Andernfalls wird die Mitarbeiter-

nummer und das Datum gespeichert.

Damit sich vom Küchenpersonal, bei Ende der Essensausgabe nicht mehr drum kümmern braucht,

sollte mein Programm die Liste speichern, sich selbst beenden und der PC OHNE NACHFRAGE runter

fahren. Am nächsten Arbeitstag schaltet das Küchenpersonal halt morgens den PC wieder an.

Der PC muß ja nicht noch den ganzen Nachmittag, die ganze Nacht und ein Vormittag laufen.

Theoretisch reicht da die Zeit, in der auch die Essensausgabe ist.

Die Datei kann dann am Monatsende von der Lohnbuchhaltung ausgewertet werden.

JörgG

Interessantes Projekt. Solange du es in der Hand hast, wann die Kiste runterfährt, droht keine Gefahr, weil du natürlich erst runterfährst, wenn du alles artig gespeichert & geschlossen hast.

Spannend wird es, wenn eine eifrige Mitarbeiterin oder Mitarbeiter den PC selbst runterfährt. Gibt ja verschiedene Gründe, dies zu tun. Oder es gibt 'ne Panne. Zumindest mußt du damit rechnen.

Dann ist natürlich das wichtig, was Volkmar oben in #4 beschrieben hat. Gibt ja verschiedene Möglichkeiten, daß Risiko eines Datenverlustes im solchem Fall zumindest zu minimieren.

Ich denke mal, daß du pro Scan die Werte sofort in die Datei(en) schreibt und diese auch danach sofort wieder schließt. Dann bist du sicher, daß bei einen unvorhergesehenden System-Down die bis dahin gespeicherten Daten sicher sind.

Ein kleines Restrisiko wäre dann, falls in dem Moment, wenn du grad schreibst, der Strom unterbrochen wird (USV könnte helfen oder Laptop).

Vorbeugen könntest du so einen Fall, indem du den Scan nacheinander in zwei identische Dateien schreibst. Wenn es dann mal crasht, dann hast du immer eine heile Datei (also die, die zum Zeitpunkt nicht geöffnet war).

Die andere könnte zerstört sein. Also im schlimmsten Fall würde dir in der heilen Datei gerade mal der letzte Scan fehlen.

H.Brill

Ein kleines Restrisiko hat man ja immer, z.B. Strom fällt im Gebäude aus.

Damit halt niemand was am Programm machen muß, soll es halt in den

Autostart und als Icon in die Taskleiste. Das Editfeld kann ich ja auch noch

ausblenden. Kann ja sein, daß jemand das Programm aus der Leiste holt

und dann damit 'spielt'. Das Speichern werde ich wohl nach jedem Schreiben

in die Datei machen. Am besten mit XProfans dBase Modul. Vor dem Runterfahren

wird alles noch zus. als. .csv gespeichert, damit die Buchhaltung besser damit umgehen

kann (z.B. auch in Excel).

Beim Runterfahren kommt dann auch nur die brutale Methode ohne Nachfrage

in Betracht.

Volkmar

Beim DBase mußt Du aufpassen. Mit PutRec wird zwar der Datensatz in die Datei geschrieben, aber wenn jetzt Windows endet, ist die Datei kaputt. Erst ein Close schreibt das Dateiendekennzeichen. Ohne das kann die Datei unter Umständen zwar vollständig geschrieben, aber nicht lesbar sein. So ein Problem hatte ich schon mal. Im HEX-Editor waren alle Daten sichtbar, funktioniert hat es aber nicht mehr richtig. Erst nach dem Anhängen des Schlußzeichens (1 Byte mit Hex-Code 1A) hinter dem letzten Datensatz war die Datei wieder zu gebrauchen.

Gruß Volkmar

H.Brill

Volkmar, gut zu wissen mit dem Hexcode 1A.

Wenn, dann mache ich das richtig und schließe auch gleich nach PutRec die Datei.

Aber ich hatte auch mal vor Jahren eine normale Textdatei, die nach einem Stromausfall

(2 Sekunden beim Gewitter) nicht mehr zu gebrauchen war.

War glücklicherweise nur eine Test-Datei.

Da ich sowieso den Timer verwende, kann ich auch gleich alle paar Minuten noch

extra eine Textdatei schreiben. Das verringert das Risiko nochmals.

Ansonsten sollte man da nicht zu schwarz malen.

Mal sehen, evtl. kann ich auch gleich in die Cloud schreiben.

Volkmar

Lieber eine Sicherheit mehr vorsehen, wenn es sich machen läßt. Man sollte immer mit dem Schlimmsten rechnen

Gruß Volkmar

H.Brill

So, werde mal zwischen den Gewitterschauern meinen Schwenkbraten

auf dem Kugelgrill grillen. mampf....

Jetzt mitmachen!