MDI mit Delphi 10 Seattle

[kdf]

Hallo,
ganz kurz zu MDI. Mit Delphi 6 habe ich ein paar Anwendungen mit dynamischen MDI Formularen gebaut. Das funktionierte eigentlich ganz gut.

Ich habe da etwas vor, das auf einem normalen PC und auf einem Tablet mit Windows 10 Prof. laufen soll. Wichtig ist dabei wohl eine vernünftige Bedienung mit touch zu haben. Das Handling der Fenster innerhalb einer MDI-Application erscheint mir recht komfortabel. Meine Anwendung ist ein Programm mit vielen Tabellen. Die Frage ist jetzt, gibt es Einschränkungen bei MDI gegenüber Einzelformularen? Sind da bei MDI noch nennenswerte Bugs drin?

Delphi ist jetzt D10 Seattle mit IBO.

Gruß
K.-D.

[peterbelow]

MDI funktioniert schon noch, allerdings ist dieses Framework bei Microsoft schon seit mehr als 10 Jahren auf der Abschussliste und wird in Windows 10 ein Bißchen stiefmütterlich behandelt. Das neue "In" Layout ist ein Fenster mit Tabs für die Unterfenster, ein Bißchen wie MDI mit maximierten MDI children, nur halt zusätzlich mit Tabs für die Navigation.
Die meisten Benutzer kennen das von ihrem Browser, das UI ist ihnen daher vertraut. MDI apps gibts dagegen kaum noch, bei Windows selbst verwendet es keines der mitgelieferten STandardprogramme mehr, nicht mal Wordpad.

Ein tabbed layout ist mit Delphi ziemlich einfach zu realisieren. TTabcontrol oder TPagecontrol, alClient im main form, frames für die "Seiten", fertig :wink:

[Rainer Wolff]

Bei dem tabbed Layout ist man nicht unbedingt auf Frames angewiesen, sondern kann zur Laufzeit auch die vorhandenen Fenster in die Tabs einhängen.

So ähnlich machen wir das, haben uns allerdings ein Control von TPagecontrol (inzwischen wg. Design TRzPagecontrol) abgeleitet, das bei Programmstart die anzuzeigenden TForms aus einer Konfigurationsdatei liest, Tabsheets erstellt, TXYZForms created und ins Tabsheet einhängt (Owner, Parent).

[kdf]

mit PageControl habe ich mal etwas in Delphi 6 gebaut. Das funktionierte ganz gut. Ich sehe jetzt den Vorteil gegenüber MDI nicht so ganz. Habe das derzeit wieder verworfen, da diese Unit mit den vielen Tab's so riesig und etwas unübersichtlich war. Bei MDI hat man halt eine Unit je Formular. Aber helft mir doch mal auf die Sprünge, wo sind die Vorteile gegenüber MDI?

K.-D.

[Rainer Wolff]

ich bin nur auf den Vorschlag von peterbelow eingegangen. Peter hatte Frames vorgschlagen, wir machen das halt mit stinknormalen TForms.

Aber beide Vorschläge haben für die ganzen (bisher MDI) Fenster einzelne Units (einmal TFrame, einmal TForm), die genau wie MDI-Formulare unabhängig voneinander entwickelt werden können, nicht eine Mega-Unit, in 50 Tabsheets mit Tonnen von Controls beisammen sitzen.

Tabsheet hat, zumindest, wenn es nicht zu viele Tabs sind, den Vorteil, mit einem Klick oder Touch von einem Fenster zum anderen springen zu können, und, wie erwähnt, sind ja viele oder die meisten User-Interfaces inzwischen mit Tabsheets gebaut (Browser, Delphi selber, Visual Studio...).

Bei den neueren Delphi-Controls gibt es auch so ein Seitenmenü, das man ein- und ausklappen kann, mit dem man dann weitere Kategorien verwalten kann, auch mit so nem Hamburger-Menüknopf. Weiss grad nur nicht, wie das Ding heisst, irgendwo in den Samples gibt es ein Beispiel. Da könntest du dann auch im Mainform ein Panel reinsetzen (alClient) und dann die einzelnen Fenster/Frames bei Bedarf einhängen.

[kdf]

Erstmal danke für die Info.
Ich werde wohl mal etwas mit MDI und etwas mit PageControl bauen. Eins von beiden werde ich dann später wieder verwerfen.

K.-D.

[hzzm]

Eine unwichtige, persoenliche, subjektive Meinung:

Ich finde insbesondere bei Touch-Bedienung aber auch generell MDI (im normalen Modus, wie man es so typisch erwartet) sehr frimelig.
Jedes Unterfenster einzeln minimieren oder "wiederherstellen" zu koennen, um dann mit zig kleinstfenstern in der Anwendung rumzujonglieren, wird spaetestens bei Touch zur Qual.
Das ganze Unterfenster-ge-resize braucht doch kein Mensch. Simples Menu (Tabs o.ae.) und jeden Einzelinhalt einfach erzwungen "Vollbild" darzustellen ist doch viel uebersichtlicher und Praxis-gerechter. Das ist wahrscheinlich auch der Grund, warum es von der Bildflaeche verschwindet.

Bei extrem umfangreichen Anwendungen wie Photoshop oder Blender mag das vielleicht angebracht sein, jede Datei als eigenes minimier- oder wiederherstellbares Fenster zu verwalten, aber ich glaube auch dort wird kaum ein Benutzer das wirklich nutzen und mehrere Dateien nebeneinander gleichzeitig bearbeiten. Ich arbeite jetzt seit ca. 20 Jahren fast jeden Tag mit Photoshop und die Situation stellt sich einfach nicht. Wenn man mehrere Dateien gleich abhandeln muss, laeuft es meistens eher auf eine Stapelverarbeitung raus. Wenn man eine Vorlage braucht, zieht man sie nicht als 2. Fenster/Datei daneben, sondern als Ebene unter die schon offene.
Ich wuerde an Deiner Stelle nicht auf ein totes Pferd setzen...

[kdf]

Ich bin damit jetzt einfach mal angefangen. Zunächst habe ich eine Basis mit MDI genommen. Die MDI Formulare werden Menue bei Bedarf synamisch erzeugt und zerstört, wenn sie nicht mehr benötigt werden. Es geht hier um ein Verwaltungssystem für Versicherungsverträge, das sehr komplex ist. Die Formulare z.B. für Kunden, Versicherer, Verträge, Termine sind MDI, die über PageControls die zugehörigen Daten wie Telefonverzeichnis, Bankverbindungen, Dokumente, Terminübersichten bereitstellen. Es werden sehr oft mehrere Formulare gleichzeitig benötigt. Man kann mit MDI z.B. das Hauptformular wenn nötig über 2 Monitore ziehen und hat so sehr viel Platz für 3, 4 oder 5 gleichzeitige Formulare. Wenn dies gerade nicht benötigt wird, laufen die einzelnen Formulare im Vollbildmodus. Diese flexible Handhabung geht eben mit MDI gut. Alles komplett mit PageControls wäre nicht so flexibel. Die Auswahl von Daten habe ich über Einzelformulare SDI gelöst, die über einen Button im Editcontrol dynamisch erzeugt werden und modal öffnen. Wenn der Cursor auf dem gewünschten Datensatz steht geht die Übernahme der Daten mit Doppelklick oder Butten. Die gesamte Bedienung über Menü und Pagecontrols geht so recht gut mit Tastatur und Maus, oder auch mit Touch. Alle Buttonbars für die Firebird DB sind groß genug für Touch. Schrift ist auf 12 Punkt gestellt. Das Tablet mit Windows 10 Prof. skaliert mit 150%. So hat die Oberfläche auf dem 11" Tablet eine angenehme Größe. Nicht ganz toll auf dem Tablet ist das Systemmenü, das einfach zu klein ist. Mit Stift geht das, mit Finger nicht so gut. Man sollte das mit MainMenu.OwnerDraw := true und TMenuItem.OnDrawItem ändern können. Funktioniert bei mir leider nicht. Wenn ich in DrawItem über ACanvas.Font.Size eine andere Größe zuweise, wird der Menüeintrag nicht mehr dargestellt, ist grau.

K.-D.

[freimatz]

Zitat:

Zitat von hzzm (Beitrag 1429394)

Eine unwichtige, persoenliche, subjektive Meinung:
...braucht doch kein Mensch...

Damit sprichst du mir (und vieler der Anwender meiner Software) das Menschsein ab :P

[Codehunter]

Microsoft selbst ist in diesen Dingen über die Jahre auch sehr inkonsequent gewesen. Eine Zeit lang war MDI schwer angesagt. Dann kam TabbedUI, was genau so lange "In" war, bis man für Office das RibbonUI erfand. Und zwei Tabreihen übereinander hätte wohl doof ausgesehen. Also wurde als nächstes "StackedUI" erfunden, was im Prinzip wieder das uralte SDI ist (Vorgänger von MDI), nur dass es halt jetzt über die Superbar (gemeinhin Taskleiste genannt) gruppiert wird.

Wenns dann noch richtig dicke kommt, hat der Anwender mehrere Monitore, die obendrein auch noch unterschiedliche Auflösungen haben und/oder einer hoch- und einer querformatig ausgerichtet. Da bist dann sowohl mit MDI als auch mit TabbedUI verloren. Insofern halte ich die aktuelle Präferenz von Microsoft für "StackedUI" für die beste Variante.

Heißt für mich: Ein Formular, ein Fenster. Die schiebt man sich halt als Anwender so zurecht dass es passt. Windows hat ja von Haus aus schon Mittel, dass sich Fenster am Bildschirmrand einrasten und ausrichten lassen. Man kann seinen Fenstern auch beibringen, aneinander einzurasten. So ähnlich wie das schon vor 20 Jahren der Winamp mit seinen drölfzig Toolfenstern gemacht hat.

EDIT: MDI hat für mich auch den "optischen" Nachteil, dass MDI-Childs unter Windows 10 mit dem Border von Vista-Basic gezeichnet werden. Das wirkt dann insgesamt ziemlich altbacken und unstimmig. Wobei ich das nie mit VCL-Styles getestet habe.

Zitat:

Zitat von hzzm (Beitrag 1429394)

Ich wuerde an Deiner Stelle nicht auf ein totes Pferd setzen...

Das sehe ich genauso.

[DieDolly]

Zitat:

mit PageControl habe ich mal etwas in Delphi 6 gebaut. Das funktionierte ganz gut. Ich sehe jetzt den Vorteil gegenüber MDI nicht so ganz. Habe das derzeit wieder verworfen, da diese Unit mit den vielen Tab's so riesig und etwas unübersichtlich war.

Wegen sowas muss man doch nicht gleich ein Konzept verwerfen. Code ordentlich in Unterunits aufteilen und kategorisieren wäre da die bessere Wahl gewesen.

Die Hauptunit eines meiner umfangreicheren Programme mit mehr als 80.000 LOC hat mit einer 50 zeiligen Kommentarsektion 828 Zeilen. Und selbst das kann man noch optimieren.
Der eigentliche Code ist aber in bestimmt 50 Unterunits und Funktionen sowie Prozeduren ausgelagert.

[kdf]

Für diesen Mix aus MDI, SDI und PageControl habe ich mich jetzt zunächst entschieden, da ich die Möglichkeit bei MDI habe, die Fenster beliebig und frei positionieren kann. Es ist mir wichtig, 4 - 5 Fenster so positionieren zu können, dass alle gleichzeitig für den Benutzer nutzbar sind, ohne hier zwischen Tabs schalten zu müssen. Eine Lösung allein mit PageControl kann das ja nicht. Wenn man das ggf. auch bauen könnte (wie Firefox), mit MDI ist das schon fertig. Von der Bedienbarkeit her, mit touch alleine, ist das einfacher. Die Lösung der Fenster von Microsoft (Office 2016) finde ich nicht sehr praktikabel, wenn man mit mehreren Dokumenten gleichzeitig arbeiten muß.

K.-D.

[haentschman]

Moin...:P

Zitat:

dass alle gleichzeitig für den Benutzer nutzbar sind, ohne hier zwischen Tabs schalten zu müssen. Eine Lösung allein mit PageControl kann das ja nicht.

...nur am Rande. Das AdvPageControl (TMS) kann Tabs "ausdocken" und zu seperaten Fenstern machen...und an der gewünschten Stelle wieder "eindocken". :thumb:

[freejay]

Zitat:

Zitat von haentschman (Beitrag 1429794)

Moin...:P

Zitat:

dass alle gleichzeitig für den Benutzer nutzbar sind, ohne hier zwischen Tabs schalten zu müssen. Eine Lösung allein mit PageControl kann das ja nicht.

...nur am Rande. Das AdvPageControl (TMS) kann Tabs "ausdocken" und zu seperaten Fenstern machen...und an der gewünschten Stelle wieder "eindocken". :thumb:

Waaaaaah! Das wusste ich nicht! Hätte ich schon längst mal brauchen können... Danke für die Info!

[kdf]

Zitat:

...nur am Rande. Das AdvPageControl (TMS) kann Tabs "ausdocken" und zu seperaten Fenstern machen...und an der gewünschten Stelle wieder "eindocken".

Das ist eine nette Option. Wie bedient man das über Touch? Die gleiche Anwendung soll ja auf PC, Laptop und Tablet (Win10 Prof.) laufen.
Windows 10 und Touch finde ich etwas speziell. Die eigentlichen Handy/Tablet-OS können das irgendwie besser. Werde das aber nicht implementieren wollen. Das ist mit Firebird dann recht kompliziert.

K.-D.

[haentschman]

Moin...8-)

Zitat:

Wie bedient man das über Touch?

...mußt du probieren. Ich hatte nur einmal die Gelegenheit das mit der Maus zu benutzen. :P

[kdf]

habe das jetzt mal von MDI auf SDI geändert. Bei Delphi 6 hatte ich dabei immer das Problem, dass NICHTmodale Fenster hinter dem Hauptfenster waren. Das scheint jetzt bei Delphi DX nicht mehr so zu sein. Ich habe jetzt ein Hauptfenster, das eigentlich als UI nur ein MainMenu hat. Dort werden über das Menü diverse Fenster(fsNormal) dynamisch erzeugt, schon existierende Fenster werden in den Vordergrund gebracht.

procedure TFMain.Produktgeber1Click(Sender: TObject);
begin
if FProduktgeber = nil then
begin
FProduktgeber := TFProduktgeber.Create(application);
end;
FProduktgeber.BringToFront;
end;

Diese Fenster sind jetzt niemals hinter dem Hauptfenster, sondern immer davor. Innerhalb dieser Fenster arbeite ich mit PageControls für editierbare Ansichten mit IB_Edit, IB_Memo und Tabellenansichten mit IB_Grid. Jeder editierbare TAB hat die 3 Buttonbars IB_NavigationBar, IB_UpdateBar und IB_SearchBar. Die Tabellenansichten haben kein IB_SearchBar. Es gibt dann noch etliche TAB's für Telefonbuch, Bankverbindungen u.s.w.

Die SDI-Fenster werden so eben anders als MDI im heute aktuellen Stil gezeichnet. Man kann geöffnete Fenster beliebig anordnen und in den Vordergrund bringen. Die Bedienbarkeit am PC, auch mit mehreren Monitoren, ist sehr gut. Ich hatte auch keine sonderlichen Probleme mit der Bedienung auf dem Tablet mit Finger oder Stift. Das UI sieht so recht ansprechend und modern aus und funktioniert gut.

K.-D.

[Codehunter]

Mit anderen Worten bist du jetzt doch bei meinem Vorschlag gelandet? :-)

[kdf]

Zitat:

Mit anderen Worten bist du jetzt doch bei meinem Vorschlag gelandet?

Läßt sich so richtig gut auch auf dem Tablet bedienen.

Danke an alle für die Mithilfe.

K.-D.

[Bernhard Geyer]

Zitat:

Zitat von kdf (Beitrag 1430076)

habe das jetzt mal von MDI auf SDI geändert. Bei Delphi 6 hatte ich dabei immer das Problem, dass NICHTmodale Fenster hinter dem Hauptfenster waren. Das scheint jetzt bei Delphi DX nicht mehr so zu sein.

Delphi 6 war noch für Windows 2000 ausgelegt.
Und seitdem hat Microsoft einiges an der GDI "gestrickt" um sie schneller zu machen (GDI+, Ausgabe über DirectDraw, ...). Das war jedoch nicht mehr mit der Delphi6-Implementierung 100% Kompatible.

[Codehunter]

Zitat:

Zitat von Bernhard Geyer (Beitrag 1430211)

Und seitdem hat Microsoft einiges an der GDI "gestrickt" um sie schneller zu machen (GDI+, Ausgabe über DirectDraw, ...)

Naja... "Schneller" ist relativ...