Design und Daten Entscheidungshilfe

[haentschman]

Guten Morgen alle... :hi:
ich hänge mal wieder fest. Zum einen brauche ich mal einen Tipp für das Design, da mir meines nicht wirklich optisch gefällt. (Control Auswahl). Zum anderen eine Idee zum verwalten des ganzen.

Ziel:
- ein Treeview mit Auswahl von Formularen, die dann gedruckt werden. (es kommen immer wieder welche dazu)
- jedes Formular hat für den Ausdruck Optionen, welche sich je nach Formular unterscheiden.
(meine Anordnung gefällt mir optisch nicht. Ich hab auch schon den TParamTree von TMS probiert, ist aber nicht wirklich brauchbar, da die Optionen dann mehrfach vorkommen und die dynamische Ausfüllung der ComboBoxen (Listen)
nur per HTML machbar ist und nicht lt. Anleitung funktioniert)
... ich hätte es gern in schööön :zwinker:

Jedem Node müssen die jeweiligen Optionen (Enablen / Disablen), der Filename des Formulars hinterlegt sein.
Lösungsmöglichkeiten:
1. Datenbank
- in einem anderen Projekt habe ich die Formulare incl. Options Matrix in eine Tabelle in die Datenbank gepackt.
- je nach Node wurde die Option Matrix geholt und die Options entsprechend visuell geändert.
--> erscheint mir bei diesem kleinen Projekt zu überdimensioniert
2. Objekte mit den Einstellungen
- für jedes Formular ein Objekt dem Node.Data hinterlegen
--> da stellt sich die Frage, wie die "Quellobjektdaten" hinterlegen. Hardcodiert oder z.B. als XML und einlesen

Bei der Flut an Ideen werde ich es wahrscheinlich noch schwerer haben mich zu entscheiden. Aber trotzdem... los !
:zwinker:

[FredlFesl]

Wir basteln uns ein Plugin-System

Basisklasse bzw. Interface definieren. Beinhalten sollte die Klasse z.B. folgende Methoden

Delphi-Quellcode:

Type
  TPluginDialog = Class
  public
    Function Name : String; virtual; Abstract;
    Function Description : String; virtual; Abstract;
    Function Version : String; virtual; Abstract;

    Function GetSetupDialog : TForm; virtual; Abstract;
    Procedure SaveSetupChanges; virtual; Abstract;

    Function GetPrintDialog : TForm; virtual; Abstract;
  End;

// Die Unit definiert eine Funktion
 
 Function Instance : TPluginDialog;

Pro zu druckendem Dialog erstellst Du eine Ableitung der o.g. Klasse, implementierst die virtuellen Methoden und schmeißt das Kompilat in eine BPL. Die Funktion "Instance" liefert dabei eine Instanz der Form.

Im Unterverzeichnis 'Plugins' kannst du dir eine Ordnerstruktur ausdenken und dann die BPL dort hineinkopieren.

Dein Programm liest nun einfach die Ordnerstruktur des "Plugins"-Unterverzeichnisses ein, erstellt für jedes Verzeichnis einen Knoten und für jede BPL-Datei ein Blatt. Du lädst die BPL, instantiierst ein Objekt der in der BPL definierten Klasse und hängst das an die Data-Eigenschaft des Blattknotens.

Die Beschriftung des Blattes ergibt sich aus "Instance.Name", ein eventueller Hint aus "Instance.Description". Die Versionsinformation kannst Du auch noch anzeigen.
klickt man auf ein Blatt, stellst Du auf der rechten Seite den Setup-Dialog dar. Den OK-Button zum Speichern der veränderten Einstellungen kontrollierst Du. Wenn man da drauf drückt, rufst Du "Instance.SaveSetupChanges" auf.

Ein weiterer Button "Print" ruft dann "Instance.GetPrintDialog" auf und druckt das Formular aus.

Fertig.

Das ist beliebig erweiterbar, die Ordnung (=Struktur) jederzeit änderbar. Kopiert man eine neue BPL in eines der 'Plugins'-Verzeichnisse, müsstest Du entweder neu starten oder über einen 'Rescan'-Button die Struktur wieder einlesen.

[generic]

Tabs sollten niemals in Tabs geschachtelt werden.
Deine drei Knöpfe über den Treeview würde ich in eine Speedbar oder ähnlich auslagern und mit Actions ansteuern.

[FredlFesl]

Zitat:

Zitat von generic (Beitrag 1109720)

Tabs sollten niemals in Tabs geschachtelt werden.

Wieso?

[haentschman]

Moin alle miteinander... :hi:

Danke für Eure Tipps...
Ich suche nach einer Lösung, die so wenig wie möglich Quelltextänderungen mit sich zieht beim Ergänzen eines Formulares. Inzwischen bin ich gedanklich wieder bei der DB Lösung. Vorteil: alle Informationen stehen in einem Datensatz (Bezeichnung, Dateiname, Options Matrix). Diese Datensätze eingelesen, jeden Datensatz zu einem Object gemacht, den Node aus den Daten dynamisch erstellt und das Object in Data an den Node gehängt. Dieses Vorgehen setzt dann keine Quelltextänderungen voraus, da die Informationen dem jeweiligen Node entnommen werden. Ich brauch dann nur bei einem Update die Formularinformationen (aus einer XML oder SQL Script) in die DB einlesen.

Zitat:

Tabs sollten niemals in Tabs geschachtelt werden.

...den Grund hätte ich auch gern gewußt.

ein schönes Wochenende. :hi:

[blackfin]

Zitat:

Tabs sollten niemals in Tabs geschachtelt werden.

Verstehe ich auch nicht.
Ich finde "Tabs in Tabs" eigentlich viel übersichtlicher als alles in einem Wust.
Wenn man das macht, entstehen solche "Schlag mich tot"-Einstellungsdialoge wie z.B. beim IE oder Windows Media Player :kotz: