NextCloud als Windows-Laufwerk←▼→Flixtrain-Test

delphi,software,tippstricks

Optional verzögerter Programmstart

Erstellt: 18.02.2022 Geändert: 04.05.2022 Lesedauer 1 - 2 Min.

Manchmal ist es notwendig, dass ein Programm verzögert startet, beispielsweise bei einem Neustart, damit Konfigurationsänderungen neu gesetzt werden.

Update auf „Variante 2“

Für OffSiteEdit war eine Funktion zur Reinitialisierung diverser Funktionen im Programm erforderlich. Das Meiste davon wird bei einem Programmstart sowieso ausgeführt. Zweifellos ließe sich alles in Prozeduren einpacken, damit es universell nutzbar wäre. Dennoch wäre es „Code aufblasen“ für etwas, das ein Neustart erledigen kann.

Der unschöne Aspekt daran ist der Aufwand für den Nutzer. Programm schließen, Programm neu starten, verbunden mit mehr oder minder langen Mouse-Moves.

Als zusätzliche Herausforderung muss bei OffSiteEdit eine Lösung gefunden werden, die den blockierten Mehrfachstart umgeht. Den Mehrfachstart verhindert eine Methode, die beim Delphi-Treff gut beschrieben ist.

In meiner ersten Lösung hatte ich eine feste Verzögerungszeit eingetragen, mit der eine zeitliche Überschneidung von „zu- und aufmachen“ verhindert werden sollte. Allerdings war das im täglichen Gebrauch tendenziell unzuverlässig.

Die Anstoß für eine elegantere und zuverlässige Methode gab ein Vorschlag bei StackOverflow. Diese zweiten Lösung sorgt für eine zuverlässige Austragung des Mutex. Wird im Programm der Schalter „StarteNeu“ gesetzt (ein Boolean-Wert), läuft das Programm am Ende in eine Schleife, die eine gewisse Zeit lang in kurzen Abständen fragt, ob der Mutex denn endlich ausgetragen ist, damit der gewünschte Neustart funktioniert. Damit es keine „Endlosschleife“ wird, ist das auf maximal 10 Sekunden beschränkt. So lange sollte es allerdings selbst auf sehr trägen PCs niemals dauern.

„Variante 1“ lief so ab:

Das Programm …

  1. … prüft zuerst, ob „sein“ Mutex schon existiert,
  2. … wartet eine fest eingestellte Zeit, falls ja,
  3. … versucht, „seinen“ Mutex zu setzen,
  4. … endet, bevor es überhaupt los ging, falls schon eine Instanz gestartet ist,
  5. … löscht beim Beenden „seinen“ Mutex.

Die „Variante 1“ Beispielanwendung (Quellen und Exe) als 7z-Archiv.

„Variante 2“ funktioniert so:

Das Programm …

  1. … erzeugt beim Start „seinen“ Mutex.
  2. … löscht verlässlich den Eintrag beim Beenden.
  3. … wird direkt beendet, wenn der Mutex bereits existiert (= „läuft schon“).
  4. … startet neu, wenn der Schalter „StarteNeu“ gesetzt und der „alte“ Mutex gelöscht ist

Die Prüfung von „StarteNeu“ nach dem Entfernen des Mutex mit der Abfrage-Schleife, sorgt für den schnellstmöglichen Start und gewährleistet einen definierten „Mutex-Status“.

Die „Variante 2“ Beispielanwendung(Quellen und Exe) als 7z-Archiv.

Hinweis

In „Multiuser-Umgebungen“ (z.B. TerminalServer) ist diese „schlichte Form“ womöglich unzureichend, weil es nur einen Namensraum geben kann, der für alle gilt. Wer das berücksichtigen will, sollte evtl. noch einen „Benutzernamen“ oder „Login“ oder „Rechnernamen“ … in den Mutex mit einbauen.