Überlegungen zu JvTabBar

[charlytango]

Mit tatkräftiger Hilfe von @wp_xyz konnte ich einen ersten Entwurf einer Tabbed GUI mit Komponenten aus JVCL erstellen. Was ein schöner Euphemismus ist, denn ohne seine Hilfe wäre ich absolut am Arsch.

Hier könnt ihr euch mal einen Zwischenstand zum Ansehen und testen holen. Ob und wie ich das in eine Komponente verpackt bekomme sei noch dahingestellt.

Das grundsätzliche Konzept ist es, dass man JvTabBar (also die Tabreiter-Reihe) und JvPageList (die dazu gehörende Representation der zum Tab gehörenden Seiten) so kombiniert dass das wie ein Pagecontrol funktioniert. Dazu ist lediglich in der IDE eine Verbindung nötig und an sich klappt das schon mal.

Man kann wahlweise ganz normale TForms (im Code) in die einzelnen Seiten einkleben und die Navigation klappt schon.

Die eine oder andere Herausforderung bleibt noch wenn es um eine Datenbank Applikation geht, weil ggfs in mehreren Tabs nicht gespeicherte Daten rumfliegen, aber das ist ein anderes Thema.

Was das Framework auch leisten soll, ist, dass man eine eingeklebte (ich verwende bewusst den Begriff Kleben und nicht Docked) Seite/TForm aus dem Tab lösen kann und frei fliegend dargestellt werden kann um Inhalte nebeneinander auf dem Schirm sehen zu können. Das klappt soweit auch schon.

Das Thema ist, die Übersicht über alle offenen Fenster (außer den kurzfristig verwendeten modalen Fenstern) in einer Applikation zu haben. Nämlich alle eingeklebten UND alle frei fliegenden.

Bisher habe ich das mit einer TFPObjectList gemacht in der ich die Fenster verwalte und ihnen fürs Anzeigen den Parent der Tabseite zuordne.

Jetzt ist das natürlich doppelt gemoppelt. Einerseits sind die Fenster in der Pagelist verbunden und andererseits in der Objektliste.
Wären es nur eingeklebte Fenster, könnte man als Ordnungselement auf die Objektliste verzichten, nur sind die frei fliegenden Fenster dann herrenlos.

FRAGE: Gibt es eine elegantere Lösung für das Dilemma ?

offene Diskussion ist erbeten -- THX







Ich möchte hier eine

[wp_xyz]

Hast du schon mal Screen.Forms[...] bzw. Screen.CustomForms[...] probiert? (Weiß nicht, worin der Unterschied liegt)

[charlytango]

nein, habe ich bislang nicht, ging bisher an mir vorbei.
Mal sehen was ich rausfinde.

[wp_xyz]

Die sollten die Formulare auflisten, die aktuell existieren. Um die "anklebbaren" Formulare zu kennzeichnen, könntest du sie von einem gemeinsamen Vorfahren ableiten. Oder du könntest die Tag-Eigenschaft verwenden.

[charlytango]

Ein gemeinsamer Vorfahre existiert schon, da noch eine Property dazu ist kein Problem.

Screen.Forms ist beim durchsuchen schneller als ich dachte. Das sieht erstmal gut aus.

Ich habe im gemeinsamen Vorfahren die Funktionen für rauslösen und einkleben -- mit ein paar herausforderungen bezüglich CloseQuery klappt das auch. Der Vorfahre kennt auch seinen JvTabBar.
Mit den Tests bin ich schnell dahinter gekommen dass ich eine Informationskette in den Vorfahren brauche, denn wenn ich vom Vorfahren aus das Fenster löse oder einklebe weiß das Hauptformular noch nicht dass es die Menüstrukturen der offenen Fenster aktualisieren muss.

Ich kann das selber zimmern, ich denke das bekomme ich hin.
Allerdings kann auch ein Event im Tabbar dafür Sinn machen (also eins das bei erfolgtem Einfügen oder Löschen eines Tabs getriggert wird).

@wp_xyz wie ist da deine Meinung dazu ?

[wp_xyz]

In der aktuellen svn-Version gibt es nun auch ein OnTabAdded-Event (mit dem neuen Tab als Parameter). Es feuert, wenn ein Tab mit AddTab(Caption) erzeugt und neu eingefügt wird. Achtung: da die Tabs-Collection als public-Property verfügbar ist, könnte man einen neuen Tab auch dort direkt einfügen (JvTabBar1.Tabs.Add oder sogar über tab := TJvTabBarItem.Create(JvTabBar1.Tabs)) - da wird das Event aber nicht erzeugt. Und es sind bei AddTab auch noch nicht alle Properties besetzt, wenn das Event feuert. Besonders schön ist das nicht...

Für das Schließen von Tabs gibt es bereits mehrere Events:
- OnTabClosing - beim Klick auf dem Tab-Kreuz; mit dem boolschen CanClose-Parameter kann man das Schließen verhindern
- OnTabQuery - kommt etwas später, aber auch beim Schließen per Code (CloseTab), auch hier gibt es einen Parameter, um das Schließen zu verhindern
- OnTabClosed - schlecht bezeichnet, kommt nicht nach, sondern unmittelbar vor dem Schließen des Tabs (hat als Parameter den "geschlossenen" Tab, der nach dem Schließen nicht mehr existieren würde...).

Eigentlich sind das zuviele Events für denselben Vorgang... Aber ich will's vorerst mal so belassen, zumindest bis sich jemand darüber aufregt.