Abbrechen Button in zweiter Schleife ohne Funktion

  • Hallo liebe autoit-Freunde,

    ich habe ein Problem mit meinem noch nicht ganz fertigen Shutdown-Skript.

    Es soll zu einer bestimmten Uhrzeit (basierend auf der von Windows) also keine Differenz-Funktion, den PC herunterfahren. Dies funktioniert auch ganz gut.

    Jedoch wäre ich gern in der Lage nach Betätigung des Skriptes durch "OK", es durch den Button "Abbrechen" zu unterbrechen und neu konfigurieren bzw. zu initiieren.

    Aber das bekomme ich einfach nicht auf die Reihe. Auch der Kill des kompletten Skriptes per "Abbrechen" nach Aktivierung wäre ein Fortschritt, scheitere aber selbst daran.

    Habe schon verschiedene Varianten und Schleifen probiert aber ohne Erfolg. :(

    Die entsprechende Stelle ist im Quellcode markiert, testen könnt ihr mit der Option "Herunterfahren".

    Vielen Dank im Voraus.

    Ich hoffe mal, dass ich nicht auf GUI OnEvent switchen muss. :/

  • Das Problem ist, dass du in Zeile 48 $msg verwendest, allerdings beinhaltet $msg die Nachricht die abgeschickt wurde als der OK-Button gedrückt wurde.

    Neue Nachrichten, die durch Betätigen der anderen Buttons ausgelöst werden, werden von dir nicht beachtet. Du müsstest statt $msg dort eigentlich GUIGetMsg() verwenden,

    denn das liefert dir immer die aktuellste Nachricht zurück.

    Außerdem ist deine Schleifenkonstellation so nicht zu gebrauchen, denn sie ist ziemlich cpu-intensiv (du sleepst da nirgends) und du brauchst so eine zweite MsgLoop innerhalb der anderen MsgLoop.

    Am besten du packst das ganze in die übergeordnete Schleife und hast in den Cases nur die Einstellungen. In etwa so:

  • Soweit ich weiß, benötigt man kein Sleep() für GuiGetMsg, weil da eh schon ein Sleep() eingebaut ist.

    Hier nochmal zum nachlesen:

    https://www.autoitscript.com/autoit3/docs/f…s/GUIGetMsg.htm

    Zitat

    This function automatically idles the CPU when required so that it can be safely used in tight loops without hogging all the CPU.

    Wenn man aufwendige Skripts hat und dann noch extra ein Sleep() reinhaut, kann es zum ghosting der controls kommen.

    Also man klickt auf ein control, jedoch passiert nichts, da genau beim Klick der Sleep() Befehl ausgeführt wurde. Bei 10ms ist

    es aber relativ unwahrscheinlich, aber dennoch möglich. :P

  • Und wieder Dinge die die Welt nicht braucht. Anstatt den Codern die Bevollmächtigung zu geben alles zu machen was er nur kann hält man ihn für unfähig und baut ein Sleep ein.

    Als ob das noch nicht reicht versteckt man es irgendwo in der Dokumentation wo man das nur mitbekommt wenn man sie sich von vorn bis hinten und oben nach unten alles genauestens durchliest.

    Sleep(10) hatte bei mir persönlich zumindest noch nie für Probleme gesorgt (und Sleep(100) ging sogar glaube ich auch noch).

    Ein Grund mehr für mich nur noch komplett in den OnEventModus zu wechseln.

  • Wenn man aufwendige Skripts hat und dann noch extra ein Sleep() reinhaut, kann es zum ghosting der controls kommen.

    Also man klickt auf ein control, jedoch passiert nichts, da genau beim Klick der Sleep() Befehl ausgeführt wurde. Bei 10ms ist

    es aber relativ unwahrscheinlich, aber dennoch möglich. :P

    Stimmt so nicht. Selbst wenn man gerade auf ein Control klickt solange der 10ms Sleep aktiv ist (das ist im Übrigen bei guter Programmierung zu 99% der Zeit der Fall), so wird die dadurch erzeugte Window Message einfach nur in die Warteschlange gestellt und beim nächsten Aufruf von guigetmsg() abgearbeitet. Die maximale Verzögerung vom Klick bis zur Umsetzung sollte hierbei also 10ms nicht überschreiten, im Mittel beträgt die Verzögerung wohl eher nur 5ms, was beides nicht wahrnehmbar ist. Bei Onlinespielen hast du normalerweise Verzögerungen von mind. 20ms oder sogar mehr.

    Wenn es zu starken Verzögerungen kommt liegt das eher an schlechter Programmierung, wie z.B. einer zweiten Endlosschleife innerhalb der Hauptgui Schleife. :P

  • Soweit ich weiß, benötigt man kein Sleep() für GuiGetMsg, weil da eh schon ein Sleep() eingebaut ist.

    Da ist kein "Sleep()" eingebaut, sondern eine Verzögerung, die dann greift, wenn keine Useraktion (Tastenbefehle bzw. Mausgeschubse) stattfinden!

    Was dazu führt, dass das Script LANGSAMER läuft, wenn keine Useraktion stattfindet!

    Das ist sehr deutlich zu sehen, wenn das Script bspw. (Grafik-) Objekte auf dem Bildschirm bewegt.

    Lässt man das Script laufen, bemerkt man, dass nach einiger Zeit die Objekte immer langsamer werden. Bewegt man dann bspw. die Maus, "schwuppt" wieder alles viel schneller....

    => OnEventModus FTW!

  • Und wieder Dinge die die Welt nicht braucht. Anstatt den Codern die Bevollmächtigung zu geben alles zu machen was er nur kann hält man ihn für unfähig und baut ein Sleep ein.

    Als ob das noch nicht reicht versteckt man es irgendwo in der Dokumentation wo man das nur mitbekommt wenn man sie sich von vorn bis hinten und oben nach unten alles genauestens durchliest.

    Die Automatik greift doch nur, wenn es nötig ist und nimmt dem Coder somit Arbeit ab, die er ohnehin leisten müsste, wenn er nicht möchte, dass sein PC einfriert/abstürzt. Zudem ist diese Information nicht irgendwo versteckt, sondern steht als erster (und somit wichtigster) Punkt unter Remarks (Bemerkungen)... welche - obwohl diese oft auch sehr wichtige Hinweise enthalten, gerne überlesen werden.

    This function automatically idles the CPU when required so that it can be safely used in tight loops without hogging all the CPU.

    Diese Funktion lässt die CPU bei Bedarf automatisch im Leerlauf laufen, so dass sie sicher in engen Schleifen verwendet werden kann, ohne die gesamte CPU zu beanspruchen.

    Edit:

    Was dazu führt, dass das Script LANGSAMER läuft, wenn keine Useraktion stattfindet!

    Ok, nimm alles zurück und behaupte das Gegenteil... ;)