Implement and archive Phase 5 form designer
This commit is contained in:
@@ -32,7 +32,7 @@ Besondere Risiken sind unverändert ausgeführte alte Kompilate nach einer Text
|
||||
| 02 | [IDE-Rahmen](../2026-09-06-phase-5-02-ide-rahmen/proposal.md) | 01 | Terminalbesitz, Menüs, Fenster, Dialoge, Optionen und Eingabetestpfad |
|
||||
| 03 | [Editor und inkrementelle Übersetzung](../2026-09-06-phase-5-03-editor-und-inkrementelle-uebersetzung/proposal.md) | 01, 02 | Vollständige Codebearbeitung, Diagnose und schneller aktueller Compile |
|
||||
| 04 | [Ausführung und Output](../2026-09-06-phase-5-04-ausfuehrung-und-output/proposal.md) | 01, 02, 03 | Fortsetzbare VM-Sitzung, Reset, Ausgabe, Shell und Textdruck |
|
||||
| 05 | [Formular-Designer](../../phase-5-05-formular-designer/proposal.md) | 01, 02, 03 | Visuelles Gestalten und konsistenter Ereigniscode |
|
||||
| 05 | [Formular-Designer](../2026-09-06-phase-5-05-formular-designer/proposal.md) | 01, 02, 03 | Visuelles Gestalten und konsistenter Ereigniscode |
|
||||
| 06 | [Debugger und Direktfenster](../../phase-5-06-debugger-und-direktfenster/proposal.md) | 03, 04 | Quellgenaues Debuggen, Watches, Immediate, History und Fehlerhalte |
|
||||
| 07 | [Hilfesystem](../../phase-5-07-hilfesystem/proposal.md) | 02, 03 | Offline-Markdown-Hilfe und Kontextnavigation |
|
||||
| 08 | [Integration und Phasenabnahme](../../phase-5-08-integration-und-phasenabnahme/proposal.md) | 01–07 | Durchgängiger Arbeitsablauf, Befehlsabdeckung und nachgewiesener PLAN-Status |
|
||||
|
||||
@@ -0,0 +1,2 @@
|
||||
schema: spec-driven
|
||||
created: 2026-09-06
|
||||
@@ -0,0 +1,30 @@
|
||||
## Context
|
||||
|
||||
`tb_ui::frm::FormFile`/`FormNode` enthalten Klassen, Eigenschaften, Kinder und Code. Der Writer erhält unveränderte Eingaben und kanonisiert geänderte Formulare; `Index = 0` ist strukturell relevant. Frontend-Forms-Metadaten kennen Klassen, Properties und Ereignissignaturen. Die Runtime kennt FormsModel und TextScreen. Der Designer nutzt die Dokumentaktionen aus 01, Fenster aus 02 und Codeoperationen aus 03.
|
||||
|
||||
## Goals / Non-Goals
|
||||
|
||||
**Goals:** Dasselbe gespeicherte Formular führt zu derselben Runtime-Struktur; alle Designaktionen lassen sich ohne Programmausführung prüfen.
|
||||
|
||||
**Non-Goals:** Neuer FRM-Parser, zweite Property-Datenbank, eigenes Layoutformat, Ausführen von Load/Click/Timer in der Vorschau.
|
||||
|
||||
## Decisions
|
||||
|
||||
1. Der Designer bearbeitet den vorhandenen FormFile-Baum. Editor und Designer teilen das Dokument, nicht nur gelegentlich synchronisierte Kopien. Stabile editorinterne Objektidentitäten werden nicht aus flüchtigen Runtime-Katalog-IDs abgeleitet. Der Compile-Katalog wird aus dem jeweiligen Baum neu erzeugt; ein reiner Wertwechsel und ein struktureller Wechsel invalidieren den Cache aus 03 entsprechend.
|
||||
2. Eine isolierte Preview-FormsModel-Instanz wird aus dem Dokument aufgebaut und auf TextScreen gerendert. Ihre Aufgabe ist ausschließlich Geometrie/Darstellung; VM-Callbacks und Timer sind nicht aktiv. Auswahlrahmen, Raster und Handles legt die IDE darüber. Vorhandene Berechnung von Containerkoordinaten und Control-Defaults wird wiederverwendet; Runtime-Fokus-/Hit-Test darf Designer-Auswahl nicht verschlucken.
|
||||
3. Toolbox, Properties und Event-Auswahl werden aus vorhandenen Klassen-/Property-/Event-Metadaten abgeleitet. Dazu gehören auch bereits ergänzte Spinvarianten; die kürzere historische Toolbox-Liste darf unterstützte Klassen nicht still ausschließen. Timer erhält eine sichtbare Designmarke, obwohl er zur Laufzeit unsichtbar ist. Ein Tabellen-Test bindet jede designfähige Klasse an einen Platzier-/Persistenznachweis.
|
||||
4. Drag, Größenänderung, Mehrfachaktionen, Propertyedit und Menüumordnung sind Dokumenttransaktionen mit gemeinsamem Undo. Geometrie wird vor Commit gegen Container und gültige Wertebereiche geprüft. Text- und Control-Zwischenablage unterscheiden sich durch den aktiven Modus; Copy/Paste eines Containers nimmt seine Kinder mit. Einfügen vergibt konfliktfreie Namen/Indizes.
|
||||
5. Properties Bar folgt der Referenz: F2 auf Value, F10 Menü/Properties, keine Statuszeile. Menüdesigner und Palette sind konkrete Kindfenster des Rahmens. Supported-Shortcut-Liste kommt aus den vorhandenen Forms-Verträgen; bekannte nicht unterstützte Importwerte werden nicht als gültige Wahl angeboten. Menu.Caption, Indent/Outdent, Reihenfolge, Index und Flags bleiben direkt im FormNode-Baum.
|
||||
6. F12 erzeugt Code mit der vorhandenen Ereignissignatur einschließlich BYREF-/Typ- und Indexparametern. Vorhandene Handler werden parsergestützt gesucht, nicht durch bloße Teilstrings. Neue Handler verwenden den Prozedurerzeugungsweg aus 03. Beim Umbenennen werden gebundene Namen und sicher aufgelöste Objektverweise in allen betroffenen Projektdokumenten als eine Transaktion geändert; bei Konflikt oder unklaren betroffenen Referenzen wird vollständig abgebrochen. Ungebundener alter Code wird bei Löschen als solcher erkennbar erhalten, nicht automatisch entfernt.
|
||||
7. Designer→Code→Designer und Save/Reopen verwenden dieselbe FRM-Ausgabe aus 01. Binärimporte benötigen einen Text-Zielpfad. Das gespeicherte Ergebnis wird zusätzlich vom bestehenden CLI-Compiler geladen, damit Preview-Erfolg keinen fehlerhaften FRM-Export verdeckt.
|
||||
|
||||
## Risks / Trade-offs
|
||||
|
||||
- Baumänderung verschiebt Katalog-IDs → editorinterne Identität separat, Katalog neu bilden; keine gespeicherten Runtime-Indizes als Editorreferenz.
|
||||
- Rename beschädigt Code → token-/symbolgebundene Änderungen, Konfliktabbruch ohne Teiländerungen; keine globale String-Ersetzung.
|
||||
- Vorschau führt Programmcode aus → nur Forms-Darstellung ohne VM; Test mit Load-/Timer-Handlern, deren Nebenwirkung ausbleiben muss.
|
||||
- Preview und Runtime laufen auseinander → Save/Reopen plus Runtime-Rendervergleich für dasselbe Formular; Runtime-Nachweis im Integrationschange 08.
|
||||
|
||||
## Migration Plan
|
||||
|
||||
Designeraktionen bauen auf bestehenden Formaten auf; keine Formatmigration. Unveränderte Formulare behalten ihre Originalausgabe, geänderte die bestehenden kanonischen Regeln. Umsetzung ist nach 01–03 möglich; der gemeinsame Run-Arbeitsablauf wird nach 04 in 08 abgenommen.
|
||||
@@ -0,0 +1,28 @@
|
||||
## Why
|
||||
|
||||
FormFile, Klassenmetadaten und Forms-Rendering existieren, aber Formulare können noch nicht in der IDE gestaltet werden. Der Designer soll dieselbe FRM-Struktur bearbeiten, die Compiler und Laufzeit bereits verstehen.
|
||||
|
||||
## What Changes
|
||||
|
||||
- Integrierter Designer mit Toolbox/Tools, Platzieren, Auswahl, Verschieben, Skalieren, Raster und Undo.
|
||||
- Properties Bar, Menüdesigner und Farbpalette gemäß IDE-Referenz; alle unterstützten Designzeit-Controlklassen einschließlich Arrays.
|
||||
- Gemeinsames Formulardokument für Designer und Code, sichere Namen-/Containeränderungen und persistente FRM-Ausgabe.
|
||||
- F12/Event Procedures und Shift+F12/Form mit signaturgerechter Ereignisprozedur-Erzeugung und Navigation.
|
||||
|
||||
## Capabilities
|
||||
|
||||
### New Capabilities
|
||||
|
||||
- `ide-formulardesigner`: Integrierter Designer mit Toolbox/Tools, Platzieren, Auswahl, Verschieben, Skalieren, Raster und Undo.
|
||||
|
||||
### Modified Capabilities
|
||||
|
||||
Keine bestehenden Anforderungen werden ersetzt; die neue IDE-Fähigkeit ergänzt die vorhandenen Laufzeit- und Dateiformatverträge.
|
||||
|
||||
## Impact
|
||||
|
||||
tb-ide-Designer, vorhandenes tb-ui::frm::FormFile, FormsModel und tb-frontend-Forms-Metadaten. Keine zweite FRM-Implementierung und keine Programmausführung als Designvorschau.
|
||||
|
||||
**Abhängigkeiten:** [phase-5-01-projekt-und-dokumentmodell](../2026-09-06-phase-5-01-projekt-und-dokumentmodell/proposal.md), [phase-5-02-ide-rahmen](../2026-09-06-phase-5-02-ide-rahmen/proposal.md), [phase-5-03-editor-und-inkrementelle-uebersetzung](../2026-09-06-phase-5-03-editor-und-inkrementelle-uebersetzung/proposal.md).
|
||||
|
||||
**Gesamtplanung:** [Phase-5-Übersicht](../2026-09-06-phase-5-01-projekt-und-dokumentmodell/phase-5-uebersicht.md). Die Nummern geben eine gültige Umsetzungsreihenfolge an; OpenSpec erzwingt Change-Abhängigkeiten nicht automatisch.
|
||||
@@ -0,0 +1,47 @@
|
||||
## Purpose
|
||||
|
||||
Ermöglicht das visuelle Erstellen und Bearbeiten der bestehenden Formular- und Controlmodelle mit gemeinsamem Ereigniscode und kompatibler FRM-Persistenz.
|
||||
|
||||
## ADDED Requirements
|
||||
|
||||
### Requirement: Designfläche und vollständige Toolbox
|
||||
Der Designer SHALL Formularfläche, Toolbox und gleichwertiges Tools-Menü anbieten. Alle in den bestehenden Forms-Metadaten unterstützten Designzeit-Controlklassen SHALL platzierbar sein, einschließlich Datei-/Verzeichnis-/Laufwerkslisten, Timer, Container, Scroll- und Spin-Controls. Werkzeugwahl mit Aufziehen und Toolbox-Doppelklick SHALL neue Controls mit gültigen Defaults und eindeutigen Namen erzeugen. Die Designvorschau MUST NOT Ereigniscode oder Laufzeittimer ausführen.
|
||||
|
||||
#### Scenario: Jede Controlklasse
|
||||
- **WHEN** jede unterstützte Designzeitklasse einmal aus Toolbox oder Tools eingefügt wird
|
||||
- **THEN** entsteht ein gültiger Eintrag im Formulardokument und nach Speichern/Wiederöffnen dieselbe Klasse mit ihren Eigenschaften
|
||||
|
||||
### Requirement: Auswahl und Geometrie
|
||||
Ausgewählte Controls SHALL Sizing Handles zeigen. Drag SHALL verschieben und Handles SHALL skalieren; Pfeile SHALL um eine Zelle, Ctrl+Pfeile um fünf Zellen und Shift+Pfeile die Größe ändern. Tab/Shift+Tab SHALL die Controlauswahl wechseln, Ctrl+Klick SHALL eine Mehrfachauswahl bilden, Grid Lines SHALL das Raster umschalten. Koordinaten SHALL sich auf den tatsächlichen Container beziehen und ungültige Größen SHALL ohne Dokumentbeschädigung abgewiesen werden.
|
||||
|
||||
#### Scenario: Container und Mehrfachauswahl
|
||||
- **WHEN** mehrere Controls innerhalb eines Frame ausgewählt und per Tastatur verschoben werden
|
||||
- **THEN** ändern sich ihre relativen Positionen um denselben Betrag, andere Controls bleiben unverändert und Undo stellt die gesamte Aktion zurück
|
||||
|
||||
### Requirement: Properties Bar und Bearbeitungsaktionen
|
||||
Die Properties Bar SHALL Property-/Value-Auswahl, Spalte/Zeile und Breite/Höhe anzeigen. F2 SHALL die Value-Box fokussieren und F10 zwischen Menüleiste und Properties Bar wechseln. Im Designer SHALL keine Statuszeile erscheinen. Edit→Cut/Copy/Paste/Clear/Undo SHALL auf die ausgewählten Controls wirken und beim Einfügen gültige Namen, Eltern und Array-Indizes herstellen. Klassenabhängige Propertytypen, Wertebereiche und schreibgeschützte Eigenschaften SHALL berücksichtigt werden.
|
||||
|
||||
#### Scenario: Ungültige Eigenschaft
|
||||
- **WHEN** eine Eigenschaft außerhalb ihres gültigen Bereichs oder mit falschem Typ eingegeben wird
|
||||
- **THEN** bleibt ihr alter Wert erhalten und die Fehlermeldung benennt Control und Eigenschaft
|
||||
|
||||
### Requirement: Menüdesigner und Farbpalette
|
||||
Menu Design Window SHALL Caption mit Access-Key/Separator, CtlName, Tag, Index, Checked, Enabled, Visible, Separator und unterstützte Shortcuts bearbeiten. Einfügen, Löschen, Ebene und Reihenfolge SHALL die Menühierarchie konsistent ändern. Color Palette SHALL ForeColor/BackColor und das Auftragen auf die Form unterstützen. Window SHALL Toolbox, Color Palette, Menu Design Window, Help und die Formliste bedienen.
|
||||
|
||||
#### Scenario: Menü mit Array und Untermenü
|
||||
- **WHEN** ein Untermenü mit Access-Key und ein indiziertes Menüelement erstellt, umgeordnet und gespeichert werden
|
||||
- **THEN** bleiben Hierarchie, Reihenfolge, Index, Shortcut und Darstellung nach Wiederöffnen und Kompilieren erhalten
|
||||
|
||||
### Requirement: Dokumentkonsistenz und Umbenennen
|
||||
Designer und Code SHALL dasselbe FRM-Dokument ändern. Änderungen an Formularstruktur, Properties und Code SHALL gemeinsam gespeichert und rückgängig gemacht werden können. Control-/Form-Umbenennen SHALL gebundene Ereignisnamen und eindeutig auflösbare Codeverweise anpassen; Namenskonflikte oder nicht sicher auflösbare betroffene Verweise SHALL die Umbenennung ohne Teiländerung verhindern. Löschen SHALL vorhandenen Code nicht stillschweigend entfernen.
|
||||
|
||||
#### Scenario: Umbenennen mit Ereigniscode
|
||||
- **WHEN** ein Button mit Click-Prozedur umbenannt wird
|
||||
- **THEN** sind Control, Handler und eindeutig gebundene Verweise konsistent umbenannt; Undo stellt alle betroffenen Teile gemeinsam wieder her
|
||||
|
||||
### Requirement: Ereignisprozeduren und Moduswechsel
|
||||
F12/Event Procedures SHALL Objekt und zulässiges Ereignis wählen und die vorhandene passende Prozedur öffnen oder genau eine Prozedur mit der dokumentierten Signatur erzeugen. Control-Arrays SHALL die richtigen Indexparameter erhalten. Shift+F12/View→Form SHALL zum zugehörigen Formular und Control zurückkehren. Der Wechsel MUST ungespeicherte Änderungen erhalten.
|
||||
|
||||
#### Scenario: Ereignis zweimal öffnen
|
||||
- **WHEN** das Click-Ereignis eines Control-Arrays zweimal über F12 geöffnet wird
|
||||
- **THEN** existiert genau eine signaturgerechte Prozedur mit Indexparameter und beide Aufrufe führen dorthin
|
||||
@@ -0,0 +1,20 @@
|
||||
## 1. Designmodell und Vorschau
|
||||
|
||||
- [x] 1.1 Den FormFile-Dokumentbaum aus 01 mit stabilen Designobjekt-IDs an einen isolierten Preview-FormsModel/TextScreen anbinden; Tests belegen identische Geometrie und ausbleibende Load-/Timer-Nebenwirkungen.
|
||||
- [x] 1.2 Toolbox und Tools-Menü aus den vorhandenen Klassenmetadaten ableiten und Platzieren per Doppelklick/Aufziehen umsetzen; ein tabellarischer Test erzeugt jede unterstützte Designzeitklasse einschließlich Spinvarianten und Timer.
|
||||
- [x] 1.3 Auswahl, Tab-Reihenfolge, Ctrl+Klick-Mehrfachauswahl, Drag, Handles und Raster implementieren; Maus-/Tastentests belegen Containerkoordinaten sowie 1-/5-Zellen-Schritte und Shift-Skalierung.
|
||||
|
||||
## 2. Eigenschaften und strukturierte Änderungen
|
||||
|
||||
- [x] 2.1 Properties Bar mit F2-/F10-Fokus und typisierter Propertybearbeitung implementieren; Tests prüfen gültige/ungültige Werte, sichtbare Koordinaten und fehlende Designer-Statuszeile.
|
||||
- [x] 2.2 Control-Cut/Copy/Paste/Clear und Undo über gemeinsame Dokumenttransaktionen umsetzen; Tests belegen Containerkinder, konfliktfreie Namen/Array-Indizes und vollständige Rücknahme einer Mehrfachaktion.
|
||||
- [x] 2.3 Den Menüdesigner für Caption, CtlName, Tag, Index, Flags, Shortcut, Ebenen und Reihenfolge implementieren; ein FRM-Roundtrip prüft Access-Keys, Separatoren und indizierte Untermenüs.
|
||||
- [x] 2.4 Color Palette und Designer-Window-Befehle anbinden; Eventtests prüfen Fore-/BackColor-Auftrag, Werkzeugfenster und Formauswahl.
|
||||
- [x] 2.5 Form-/Control-Umbenennung über gebundene Codeverweise transaktional ausführen und Löschfolgen sichtbar machen; Tests belegen Handleranpassung, konfliktbedingten Gesamtabbruch und Erhalt vorhandenen Codes.
|
||||
|
||||
## 3. Ereignisse und Dateivertrag
|
||||
|
||||
- [x] 3.1 F12/Event Procedures mit vorhandenen Eventsignaturen an die Prozedurerzeugung aus 03 binden; Tests prüfen Wiederaufruf ohne Duplikat, BYREF-/Typ- und Control-Array-Indexparameter.
|
||||
- [x] 3.2 Shift+F12/View→Form und Codewechsel an dieselbe Dokumentidentität binden; eine Eingabefolge belegt unveränderte ungespeicherte Struktur und Cursor-/Controlauswahl.
|
||||
- [x] 3.3 Save/Reopen und Binärimport→Textziel für gestaltete Formulare prüfen; bestehender FRM-Parser und CLI-Compiler müssen Struktur, Array-Indizes, Properties und Code gemeinsam akzeptieren.
|
||||
- [x] 3.4 Designerbedienung dokumentieren und alle Spec-Szenarien in verification.md zuordnen; IDE-/FRM-/Forms-Metadaten-Tests und Formatprüfung müssen bestehen.
|
||||
@@ -0,0 +1,81 @@
|
||||
# Verification Report: phase-5-05-formular-designer
|
||||
|
||||
Stand: 2026-09-06. Geprüft wurden Proposal, Design, alle zwölf Tasks und alle
|
||||
sechs Anforderungen samt Szenarien gegen den aktuellen Arbeitsstand.
|
||||
|
||||
## Ergebnis
|
||||
|
||||
| Dimension | Ergebnis |
|
||||
| --- | --- |
|
||||
| Completeness | 12/12 Aufgaben; 6/6 Anforderungen umgesetzt |
|
||||
| Correctness | Alle sechs Spec-Szenarien durch ausführbare Prüfungen abgedeckt |
|
||||
| Coherence | Gemeinsames FRM-Dokument, vorhandene Metadaten, FormsModel/TextScreen, gemeinsamer Prozedur- und Undo-Pfad |
|
||||
| Offene Befunde | 0 CRITICAL, 0 WARNING, 0 SUGGESTION |
|
||||
|
||||
## Anforderungen und Szenarien
|
||||
|
||||
Die Designerprüfungen liegen in `crates/tb-ide/tests/designer.rs` und bedienen
|
||||
die produktiven App-Aktionen sowie den realen Event-Dispatcher/Renderer.
|
||||
|
||||
| Anforderung / Scenario | Implementierung | Nachweis |
|
||||
| --- | --- | --- |
|
||||
| Designfläche und vollständige Toolbox / Jede Controlklasse | `designer::tools`, `design_place`, `preview`, `design_mouse`, `design_render`; `commands::menus` | `all_metadata_tools_persist_and_preview_matches_runtime_without_events`: alle 17 Toolboxvarianten, einschließlich VSpin/HSpin, Browserklassen und Timer, persistieren mit gleichen wirksamen Properties. Pixelvergleich mit FormsModel-Rendering; aktivierter 1-ms-Timer bleibt in der Vorschau ohne Deadline/Ereignis, Load-/Timer-Code wird nicht ausgeführt. `toolbox_double_click_tool_drag_grid_and_window_form_selection` prüft Doppelklick und Tools-Aufziehen. Menu wird durch die Menütests abgedeckt. |
|
||||
| Auswahl und Geometrie / Container und Mehrfachauswahl | `design_select`, `design_geometry`, `design_resize`, `design_tab`, `design_mouse`; öffentliche Laufzeitgeometrie `FormsModel::rect` | `container_multiselect_keyboard_drag_resize_and_undo`: tatsächliche Framekoordinaten, Ctrl+Klick, Tab/Shift+Tab, 1-/5-Zellen-Bewegungen, Shift-Skalierung, Drag und gemeinsames Undo. `all_eight_handles_resize_transactionally_and_preserve_identity_after_structure_edits`: alle acht Handles, Ablehnung unzulässiger Geometrie und stabile IDs über Indexänderung, Löschen, Neuanlage und Undo. |
|
||||
| Properties Bar und Bearbeitungsaktionen / Ungültige Eigenschaft | `design_property`, `design_value_focus`, `design_bar`, `design_copy/paste/delete`; `Project::edit_form/undo` | `property_bar_types_readonly_and_no_status_line`: Typen/Bereiche/readonly, F2/F10, sichtbare Geometrie, keine Statuszeile, Spin-Größenvertrag. Runtime-Setter validieren zusätzlich kontextabhängige Propertyregeln in einer isolierten Vorschau. `clipboard_children_arrays_and_delete_preserve_code`: Containerkinder, neue Namen, erhaltene Array-Indizes, Cut/Paste/Clear und vollständiges Undo. |
|
||||
| Menüdesigner und Farbpalette / Menü mit Array und Untermenü | `design_action`, `design_submit`, `design_menu_move/commit`, `design_tool_render`; `forms::menu_shortcuts` | `menu_hierarchy_arrays_shortcuts_and_palette_use_events`: Access-Key, Separator, Index=0, Shortcut, Hierarchie/Reihenfolge, FRM-Roundtrip und Kompilierung; Fore-/BackColor-Auftrag. `menu_indent_outdent_rename_and_field_changes_have_one_undo`: Ebenenwechsel und eine Undo-Einheit für Name und Dialogfelder. `property_menu_buttons_palette_drag_and_modal_mouse_are_connected`: echte Property-/Menübuttons, Farbdrop und Modalität. |
|
||||
| Dokumentkonsistenz und Umbenennen / Umbenennen mit Ereigniscode | `design_rename_with`; `ProjectCompiler::bound_form_references`; opt-in Referenzaufzeichnung im regulären Sema; `Project::commit_transaction/undo` | `bound_rename_across_documents_is_atomic_and_undo_restores_all`: Control, Handler und qualifizierte Verweise in anderen Modulen; Undo aus einer beteiligten Datei; Konflikt-/Syntaxabbruch ohne Teiländerung. `rename_preserves_shadowed_names_and_handles_form_aliases_and_include_calls`, `shared_include_ambiguity_aborts_rename_and_event_defaults_use_includes`, `imported_type_shadow_is_not_an_object_reference_during_rename`: Kommentare/Strings, gleichnamige Variablen, importierte UDT-Felder, Prototypen/Aufrufe, Formularalias und mehrdeutig gemeinsam genutzte Includes. Löschen erhält Code und meldet ungebundene Handler sichtbar. |
|
||||
| Ereignisprozeduren und Moduswechsel / Ereignis zweimal öffnen | `design_event`, `event_parameters`, gemeinsames `App::new_procedure_text`; `show_document/design_enter` | `clipboard_children_arrays_and_delete_preserve_code` öffnet Array-Click zweimal ohne Duplikat. `event_array_signature_twice_and_shared_form_identity` prüft außerdem DragOver zweimal mit Index/CONTROL/SINGLE/INTEGER, gleiche Dokumentidentität, Cursor und Controlauswahl. `existing_default_typed_event_and_all_metadata_signatures_compile`: vorhandene DEFtype-Signatur und alle CommandButton-Events kompilieren. `events_with_the_same_name_are_local_to_their_form`: gleichnamige Ereignisse zweier Formulare bleiben getrennt. |
|
||||
|
||||
## Persistenz und Compilergrenze
|
||||
|
||||
- `binary_designer_import_requires_text_target_and_compiles` bearbeitet einen
|
||||
echten Binärimport, verlangt ein separates Textziel, erhält die Originalbytes
|
||||
und lädt das Ergebnis über den bestehenden Compilerpfad.
|
||||
- `crates/tb-cli/tests/project.rs::designer_frm_is_accepted_by_the_standalone_cli_compiler`
|
||||
erzeugt ein Formular samt Control-Array und Ereigniscode über App-Aktionen,
|
||||
speichert es mit dem vorhandenen Writer, startet den echten `tbc build`-Prozess
|
||||
und lädt das erzeugte TBC erneut. Die zusätzliche Abhängigkeit auf tb-ide
|
||||
gilt ausschließlich für CLI-Tests; es gibt keine neue externe Bibliothek.
|
||||
- Der FRM-Writer lässt explizite Defaultwerte weg. Die Roundtripprüfung
|
||||
vergleicht Klassen, Namen, Hierarchie, explizite Array-Indizes und sämtliche
|
||||
wirksamen Metadatenproperties, statt unterschiedliche interne Maps als
|
||||
Formatfehler zu behandeln.
|
||||
|
||||
## Behobene Befunde während der Verifikation
|
||||
|
||||
- Acht Größenhandles einschließlich linker/oberer Kanten und zusammenfallender
|
||||
Handles kleiner Controls werden korrekt aufgelöst.
|
||||
- Designerzeichen erreichen den Quelltexteditor nicht. Property-/Menübuttons
|
||||
sind im nichtmodalen Dispatcher angebunden; Dialoge sperren Hintergrundaktionen.
|
||||
- Fenster-/Formwechsel aktualisieren die Designeridentität. Die ursprüngliche
|
||||
Befehlsidentität beim Weiterschalten eines Fensters bleibt erhalten.
|
||||
- Positions-/Größenanzeige bleibt rechts sichtbar, auch wenn Propertytext lang ist.
|
||||
- Umbenennen nutzt die Importkontexte der tatsächlich übersetzten Module.
|
||||
Synthetische Importprototypen ohne physische Quellposition werden nicht editiert.
|
||||
Echte Prototypen und Prozeduraufrufe werden semantisch erfasst; keine globale
|
||||
Bezeichnerersetzung beschädigt unabhängige Variablen/UDT-Felder.
|
||||
- Ereigniserzeugung verwendet denselben includebewussten New-Sub-Pfad wie der
|
||||
Editor. Vorhandene Formularalias-/DEFtype-Signaturen und gleichnamige Events
|
||||
unterschiedlicher Formulare werden korrekt zugeordnet.
|
||||
- Aktivierte Timer bleiben im Dokument erhalten, sind in der Vorschau aber
|
||||
ausdrücklich deaktiviert. Es existiert dort keine VM oder Event-Pump.
|
||||
|
||||
- Der workspaceweite Clippy-Lauf fand die bereits vorhandene Shell-Hilfsfunktion
|
||||
hinter dem Testmodul in `tb-runtime/src/host.rs`. Sie wurde unverändert vor
|
||||
das Testmodul verschoben; das beseitigt die Ordnungswarnung ohne Verhaltensänderung.
|
||||
|
||||
## Abschlussprüfungen
|
||||
|
||||
- `cargo test --workspace`: 567 bestanden, 0 fehlgeschlagen, 2 bestehende
|
||||
Ignore-Fälle (Golden-Output-Generator und externe VBDOS-Referenzsuite).
|
||||
Darin: 17 Designer-Integrationstests und der zusätzliche echte CLI-Compilerpfad.
|
||||
- `cargo clippy --workspace --all-targets -- -D warnings`: bestanden.
|
||||
- `cargo fmt --all -- --check`: bestanden.
|
||||
- `git diff --check`: bestanden.
|
||||
- `openspec validate --all --strict`: 23/23 gültig. Vorhandene INFO-Hinweise
|
||||
zur Länge von Requirement-Texten sind keine Validierungsfehler.
|
||||
|
||||
Keine angeforderte Prüfdimension wurde ausgelassen. Die Tests sind headless;
|
||||
für diesen Change wurde keine interaktive GUI-/Emulatorsitzung benötigt.
|
||||
Die gemeinsame Phase-5-Abnahme bleibt Aufgabe von Change 08. Der Change ist
|
||||
vollständig umgesetzt und zur separaten Synchronisierung/Archivierung bereit.
|
||||
Reference in New Issue
Block a user