# Befund: Fenstermenü falsch positioniert und „File“ hervorgehoben Datum: 08.09.2026, Validierung Phase 6 (Change 07), Windows Terminal / cmd.exe, `target\debug\tb`. ## Beobachtung (Screenshot Run-Fenster) - Aktives Fenster: Run-Fenster (Magenta-Titel), Position etwa Spalte 3, Zeile 6. - Nach Öffnen des Fenstermenüs erscheint der Aufklappbereich (Restore, Move, Size, Minimize, Maximize, Close) in Zeile 1 direkt unter der Menüleiste, beginnend an der linken Fensterkante, und überdeckt den Titel des dahinterliegenden Codefensters. - Gleichzeitig ist der Hauptmenüeintrag „File“ in der Menüleiste hervorgehoben, obwohl kein Menüleistenmenü geöffnet wurde. Das Run-Fenster ist nur das Beispiel; der Fehler betrifft alle Fenster gleich, da Zustand und Renderpfad des Control-Menüs fensterartunabhängig sind. ## Erwartung - Aufklappbereich an das Symbol `[≡]` des aktiven Fensters angehängt: linke Spalte = Symbolspalte, bevorzugt unmittelbar unter der Titelzeile. - Reicht der Platz unten nicht (z. B. minimiertes Fenster am unteren Rand), klappt das Menü nach oben und grenzt mit seiner Unterkante an die Titelzeile; es bleibt immer vollständig im Terminalbereich und sichtbar mit dem Fenster verbunden. - Gleiche Regel für alle Fensterarten. - Kein hervorgehobener Menüleistentitel. ## Ursache im Code (Stand 6e742d9) - `crates/tb-ide/src/app.rs`, `Command::ControlMenu`: setzt `self.menu = Some((0, 0))` und damit den Menüleistenindex 0 („File“) als ausgewählt. - `crates/tb-ide/src/render.rs`, Menüleiste: hebt den Titel `i` hervor, wenn `self.menu == Some((i, _))`; bei Control-Menü also „File“. - `crates/tb-ide/src/render.rs`, Popup: `Rect::new(x, 1, …)` mit `x` = linke Fensterkante; die Zeile ist fest 1 statt Titelzeile des Fensters + 1. ## Korrektur (08.09.2026) - `crates/tb-ide/src/app.rs`: `control_menu` trägt jetzt die eigene Auswahl (`Option`); `Command::ControlMenu` setzt `menu` nicht mehr. Gemeinsame Eintragsnavigation über `open_entries`/`select_open`, `menu_open()` ersetzt alle „ein Menü ist offen“-Abfragen. Neue Platzierungsfunktion `control_menu_rect` für alle Fensterarten: linke Spalte = Symbolspalte, bevorzugt unter der Titelzeile, sonst nach oben aufgeklappt bis an die Titelzeile, rechts nur so weit nach links wie nötig. - `crates/tb-ide/src/render.rs`: Popup zeichnet die offene Liste an der berechneten Position; Menüleiste hebt nur bei echter Menüleistenauswahl hervor. - `crates/tb-ide/tests/app.rs`: `control_menus_attach_to_the_symbol_of_every_window` prüft Code-, Projekt-, Output- und Immediate-Fenster, maximiert, minimiert (klappt nach oben), an den rechten Rand verschoben (rückt nach links) sowie Mausklick auf `[≡]` und auf einen Eintrag; vor der Korrektur schlug der Test mit `menu == Some((0, 0))` fehl. ## Nebenbefund: Export-Tests unter Windows Bei der Testausführung scheiterten auf unverändertem Stand 6e742d9 sechs Export-Tests (`tb-export` und `tb-ide`) mit „Zugriff verweigert (os error 5)“. Ursache in `crates/tb-export/src/lib.rs`, `prepare_publication`: Die Temporärdatei wurde nur lesend geöffnet und dann `sync_all` aufgerufen; Windows verlangt für `FlushFileBuffers` Schreibrechte. Korrektur: schreibend öffnen. Auf Linux war das Verhalten unauffällig, daher blieb es in den Gitea-Läufen unentdeckt. Für Change 07 (Aufgabe 2.2/2.4) bedeutet das: Windows-Zielprüfungen des Exports müssen mit dieser Korrektur wiederholt werden. ## Nebenbefunde: Windows-Checkout mit CRLF und Pfadtrennern Der vollständige Workspace-Lauf auf dem Windows-Prüfsystem (core.autocrlf=true) zeigte weitere plattformabhängige Fehler auf unverändertem Stand: - `crates/tb-cli/src/ide_acceptance.rs`, Referenzmatrix: suchte `#[test]\nfn …(` in Quelldateien, die im Checkout CRLF tragen. Korrektur: Suche zeilenendenneutral. - `crates/tb-cli/tests/compat.rs`: `release-formular` und `isamopen` verglichen CRLF-Sollausgaben direkt mit LF-Snapshots (die Hauptschleife normalisierte bereits, die beiden Einzeltests nicht). Korrektur: `assert_output_matches` und der `isamopen`-Vergleich normalisieren; `.gitattributes` erklärt `tests/compat/*.out` zu LF, wie der bestehende Kommentar es bereits behauptete. - `crates/tb-vm/tests/project_io.rs`: suchte den Block ```` ```mak\n ```` in `docs/dateiformate.md` (CRLF im Checkout). Korrektur: zeilenendenneutral. - `crates/tb-vm/src/project_io.rs`, `relative_path`: schrieb relative Projektverweise mit dem Plattformtrenner (`..\lib.tbl`), die drei `save_as`-Tests in `crates/tb-ide/tests/documents.rs` erwarten `/`. Unter Linux/macOS ist `\` kein Trenner, ein unter Windows gespeichertes Projekt wäre dort nicht ladbar. Korrektur: Verweise werden immer mit `/` geschrieben; beide Plattformen lösen `/` beim Laden auf. - `crates/tb-ui/src/forms.rs`, Zeichenbildtest: erwartete für die DriveListBox fest `/ ▼`; die Implementierung zeigt absichtlich den Wurzeltrenner der Plattform (`std::path::MAIN_SEPARATOR`, unter Windows `\`). Korrektur: Test plattformneutral, `docs/forms-referenz.md` nennt beide Bilder. Diese Befunde sind für Change 07 (Plattformmatrix, Aufgabe 2.2/2.4) relevant: Die Windows-Zielprüfung muss mit diesem Stand wiederholt werden. Der vollständige Workspace-Lauf unter Windows (cargo test --workspace --no-fail-fast) bestand nach den Korrekturen; die Zahlen stehen unten. ## Testlauf Windows (08.09.2026, Arbeitsstand auf 6e742d9) `cargo fmt --all -- --check` sauber, `cargo clippy -p tb-ide --tests` ohne Warnung. | Lauf | Testziele | bestanden | fehlgeschlagen | ignoriert | |---|---|---|---|---| | Vor den Nebenbefund-Korrekturen | 42 | 636 | 12 | 4 | | `cargo test --workspace --no-fail-fast`, final | 42 | 637 | 0 | 4 | ## Manuelle Gegenprobe (08.09.2026) Der Benutzer hat die Korrektur im realen Windows Terminal geprüft und als erfolgreich gemeldet: Control-Menüs öffnen fensterlokal am `[≡]`-Symbol des aktiven Fensters, die Menüleiste zeigt keinen ausgewählten Titel mehr. ## Status Behoben. Automatisiert und manuell nachgewiesen; Übergabe an Change 07 Aufgabe 2.3 als erledigter Fachbefund.