Bugfix: Stop-Button im Scheduler-Tab wird wieder aktiv

Die zentrale Status-Refresh-Timeline las den Scheduler-Use-Case aus dem unveraenderlichen GuiStartupContext. Beim regulaeren GUI-Start ohne --config ist dieser Optional leer; der via Auto-Load nachtraeglich verdrahtete Use Case wurde dadurch nie sichtbar, updateStatus wurde nie aufgerufen und der Stop-Button blieb dauerhaft deaktiviert. Die Timeline liest den Status jetzt ueber den Workspace, der den live im GuiSchedulerTab verdrahteten Use Case kennt. Co-Authored-By: Claude Opus 4.7 <noreply@anthropic.com>
2026-05-07 13:21:41 +02:00
parent 13141f9638
commit 1ea6465584
3 changed files with 36 additions and 5 deletions
@@ -1157,6 +1157,23 @@ public final class GuiConfigurationEditorWorkspace {
        updateLockState(status);
    }

+    /**
+     * Liest den aktuellen Scheduler-Status vom verdrahteten Use Case und reicht ihn an
+     * alle betroffenen Tabs weiter.
+     * <p>
+     * Im Gegensatz zu einem direkten Lesen am unveränderlichen
+     * {@code GuiStartupContext} berücksichtigt diese Methode den nach einem
+     * erfolgreichen Datei-Öffnen erst zur Laufzeit verdrahteten Use Case
+     * (Auto-Load der zuletzt geladenen Konfiguration oder manuelles Öffnen).
+     * Ist kein Use Case verdrahtet, ist der Aufruf ein No-op.
+     * <p>
+     * Muss auf dem JavaFX Application Thread aufgerufen werden.
+     */
+    public void refreshSchedulerStatus() {
+        schedulerTab.currentSchedulerUseCase()
+                .ifPresent(uc -> onSchedulerStatusRefresh(uc.getStatus()));
+    }
+
    /**
     * Aktualisiert den Sperr-Zustand des Konfig-Tabs anhand des aktuellen Scheduler-Status.
     * <p>
@@ -146,6 +146,20 @@ public final class GuiSchedulerTab {
        startButton.setTooltip(null);
    }

+    /**
+     * Gibt den aktuell verdrahteten Scheduler-Use-Case zurück.
+     * <p>
+     * Wird von der zentralen Status-Refresh-Timeline benötigt, weil der Use Case
+     * erst nach erfolgreichem Datei-Öffnen verfügbar wird (z. B. durch Auto-Load
+     * der zuletzt geladenen Konfiguration) und damit nicht im
+     * unveränderlichen {@code GuiStartupContext} steht.
+     *
+     * @return aktueller Use Case oder {@code Optional.empty()} wenn keiner verdrahtet ist
+     */
+    public Optional<SchedulerControlUseCase> currentSchedulerUseCase() {
+        return schedulerUseCase;
+    }
+
    /**
     * Aktualisiert alle Tab-Elemente anhand des aktuellen Scheduler-Status.
     * <p>
@@ -3,7 +3,6 @@ package de.gecheckt.pdf.umbenenner.adapter.in.gui;
 import org.apache.logging.log4j.LogManager;
 import org.apache.logging.log4j.Logger;

-import de.gecheckt.pdf.umbenenner.application.port.in.SchedulerStatus;
 import javafx.application.Application;
 import javafx.application.Platform;
 import javafx.event.EventHandler;
@@ -153,10 +152,11 @@ public class PdfUmbenennerGuiApplication extends Application {
     * ist, wird der Aufruf ohne Fehler übersprungen.
     */
    private void refreshAllTabStates() {
-        guiStartupContext.schedulerControlUseCase().ifPresent(uc -> {
-            SchedulerStatus status = uc.getStatus();
-            workspace.onSchedulerStatusRefresh(status);
-        });
+        // Den Use Case nicht aus dem unveränderlichen GuiStartupContext lesen, sondern
+        // den zur Laufzeit (z. B. durch Auto-Load) verdrahteten Use Case verwenden.
+        // Andernfalls bliebe der Stop-Button dauerhaft deaktiviert, weil updateStatus
+        // nie aufgerufen würde.
+        workspace.refreshSchedulerStatus();
    }

    /**