MDI Anwendung umwandeln in SDI - wie?

[Alfonso]

Hallo,

meine Delphi Anwendung, die seit vielen Jahren als MDI Applikation läuft, soll modernisiert werden.
Ich habe Zig unterschiedliche Forms, die als MDI Children über das Haiuptmenü geöffnet werden. Alle MDI Formulare sind gleichberechtigt und können parallel laufen. In der Regel ist jedoch nur ein Fenster offen.

Wenn das Programm gestartet wird, hat es nur ein leeres Mainform (maximiert) mit einem Logo in der Mitte. Oben ist ein Hauptmenü und eine Symbolleiste.

Ich habe gelesen, dass MDI veraltet ist und nicht mehr von Microsoft verfolgt wird.

Was wäre der richtige Ansatz, um MDI loszuwerden? Wie ist dann das Userinterface und die Bedienung? Gibt es noch ein Mainform? Läuft jedes Fenster autark für sich? Habe ich dann tausend Symbole in der Tasklesite? Fragen über Fragen

Gruß
Alfonso

[peterbelow]

Zitat von Alfonso:

Hallo,

meine Delphi Anwendung, die seit vielen Jahren als MDI Applikation läuft, soll modernisiert werden.
Ich habe Zig unterschiedliche Forms, die als MDI Children über das Haiuptmenü geöffnet werden. Alle MDI Formulare sind gleichberechtigt und können parallel laufen. In der Regel ist jedoch nur ein Fenster offen.

Wenn das Programm gestartet wird, hat es nur ein leeres Mainform (maximiert) mit einem Logo in der Mitte. Oben ist ein Hauptmenü und eine Symbolleiste.

Ich habe gelesen, dass MDI veraltet ist und nicht mehr von Microsoft verfolgt wird.

Was wäre der richtige Ansatz, um MDI loszuwerden? Wie ist dann das Userinterface und die Bedienung? Gibt es noch ein Mainform? Läuft jedes Fenster autark für sich? Habe ich dann tausend Symbole in der Tasklesite? Fragen über Fragen

Gruß
Alfonso

Naja, es scheint im Wesentlichen zwei weit verbreitete UIs für solche Anwendungen zu geben. Die eine ist SDI, wie von Microsoft Office-Anwendungen bekannt. Jedes "Dokument" hat ein eigenes Fenster mit eigenem Taskbar-Button und eigenem Menu, ein Mainform im strengeren Sinne gibt es nicht, die Anwendung läuft bis das letzte Dokumentfenster geschlossen wird. Das passt für Anwendungen, die wirklich sowas wie Dokumente (Files) bearbeiten, aber weniger für eine Anwendung, die z. B. mit einer Datenbank arbeitet und dem Benutzer Daten aus dieser anzeigt und zur Bearbeitung anbietet.

Das andere verbreitete Design würde ich mal "Workspace"-UI nennen. Dabei gibt es ein "Mainform" mit einem gemeinsam genutzten Menu und viele (oft verschiedene) Fenster für spezifische Aufgaben. MDI passt in dieses Schema, oder z. B. die RAD-Studio IDE. Die "Kind"-Fenster können dabei entweder im Clientbereich des Mainform angesiedelt sein (wie MDI), oder halt unabhängig von diesem (wie das alte undocked design der IDE), wobei die Kindfenster keine eigenen Taskbar-Buttons haben.

Falls eine alte MDI Anwendung zumeist mit maximierten Kindfenstern verwendet wird ist eine gute Alternative ein Workspace-Design in der Art eines Browsers (tabbed UI), wobei man nicht unbedingt Reiter (tabs) für die Navigation zwischen den "Seiten" verwenden muss (unhandlich wenn es viele werden können). Die Anwendung besteht dann aus einem Mainform, das ein Menu, eine Statuszeile und eine Navigations-Control enthält (z. B. einen left-aligned TTreeview oder TCategoryButtons oder sowas). Der Rest des Forms wird von einem client-aligned TPanel eingenommen, auf dem dann nach Bedarf TFrames oder eingebettete Forms (Borderstyle bsNone, Formstyle fsNormal, alClient-Aligned) erzeugt und angezeigt werden. Das Form verwendet eine interne Liste um die aktiven Kindfenster zu verwalten, und wenn der Benutzer auf ein anderes wechselt wird das aktive versteckt und das neue angezeigt. Das funktioniert nach meiner Erfahrung besser, als z. B. die Pages eines TPagecontrol als Parent für die Kindfenster zu verwenden oder gar alle Controls direkt auf TTabsheets zu plazieren (Alptraum!).

Der Vorteil ist halt, das man wie bei MDI die Kindfenster getrennt voneinander entwickeln kann. Dazu gehört natürlich eine saubere Trennung von UI und Datenmodell, weitgehende Vermeidung von Abhängigkeiten zwischen den Forms, etc..

[Alfonso]

Zitat von peterbelow:

Der Rest des Forms wird von einem client-aligned TPanel eingenommen, auf dem dann nach Bedarf TFrames oder eingebettete Forms (Borderstyle bsNone, Formstyle fsNormal, alClient-Aligned) erzeugt und angezeigt werden.

Wie kann ich Forms in einem Panel einbetten, die keine TFrames sind?

[DasWolf]

Ist die Umstellung weg von MDI für die Zukunft notwendig, oder wird es die nächsten Jahre weiterhin funktionieren?

[Schokohase]

Zitat von Alfonso:

Zitat von peterbelow:

Der Rest des Forms wird von einem client-aligned TPanel eingenommen, auf dem dann nach Bedarf TFrames oder eingebettete Forms (Borderstyle bsNone, Formstyle fsNormal, alClient-Aligned) erzeugt und angezeigt werden.

Wie kann ich Forms in einem Panel einbetten, die keine TFrames sind?

Man kann auch docken, das geht noch einfacher:
https://delphi-bar.blogspot.com/2017...-to-panel.html

[peterbelow]

Zitat von Alfonso:

Zitat von peterbelow:

Der Rest des Forms wird von einem client-aligned TPanel eingenommen, auf dem dann nach Bedarf TFrames oder eingebettete Forms (Borderstyle bsNone, Formstyle fsNormal, alClient-Aligned) erzeugt und angezeigt werden.

Wie kann ich Forms in einem Panel einbetten, die keine TFrames sind?

In Kode, einfach das Form erzeugen und dann sein Parent auf das Panel setzen und danach Align auf alClient. Dadurch wird das Form zu einem Control, was übrigens ein paar Unterschiede im Verhalten zur Folge hat. Einige der Events (OnActivate z. B.) feuern nicht mehr.

Im Prinzip sind Forms nicht für sowas gedacht, dafür gibt's Frames, aber wenn Du eine existierende Anwendung umdesignen willst kannst Du auf diese Art vermutlich viele der existierenden MDI Childforms ohne große Änderungen wiederverwenden.

[peterbelow]

Zitat von DasWolf:

Ist die Umstellung weg von MDI für die Zukunft notwendig, oder wird es die nächsten Jahre weiterhin funktionieren?

Meine Kristallkugel ist seinerzeit dem Y2K-Problem zum Opfer gefallen , aber vermutlich wird das MDI-Framework in Windows noch einige Jahre überleben, allerdings ohne größere Anpassungen an Änderungen der UI-Bibliothek von Windows. Es ist schon bezeichnend das praktisch keine der mit Windows gelieferten Anwendungen noch MDI ist, es gibt da offenbar schon jetzt leichte Probleme mit solchen Anwendungen auf den aktuellen Desktops (Themen, desktop composition API, Taskbar). Das wird nicht besser werden.