Hallo Forum,
Eine Frage zum Konzept: ich habe in meinem Programm eine Reihe von (Eingabe-)Parametern, die sich mehr oder weniger hierarchisch bzw. nach Themenbereichen gliedern lassen. Bisher nutze ich zur Eingabe TPageControl mit TTabSheets, wobei jedes Tab einen Themebereich abdeckt. Auf dem Tab gibt es dann verschiedene Eingaben (bestehend aus TLabel für den Namen und TEdit für den Wert - alles eventuell noch gruppiert durch TGroupBoxen).
Ich überlege gerade, wie ich dies einfacher und übersichtlicher gestalten kann und bin auf den Gedanken verfallen, dass sich ein TreeView anbieten würde; jeder Bereich (ehemals Tab) bildet einen Knoten; jeder Eintrag bildet einen Sub-Knoten bestehend aus Namen des Parameters und dem Wert. Eventuell kann man noch tiefer verzweigen - entsprechend den TGroupBoxen.
In einem weiteren Schritt schwebt mir vor, dass man die Parameter-Eingabe bzw -Änderung durch einem Click auf einen Knoten auslösen kann (direkt im Baum oder mittels Extra-PopUp).
Da ich von all dem noch wenig Ahnung habe, wollte ich hier mal nach Euren Erfahrungen, Tipps und Anregungen fragen. Ist das ganze so realisierbar, sinnvoll oder im Handling zu kompliziert? Gibt es vielleicht andere - bessere Ansätze?
Vielen Dank für jeden Input,
Photor
PS: ich probiere das erstmal an meinem Hobby-Projekt mit Lazarus aus; später will ich das auf ein größeres Delphi-Projekt in der Firma übertragen.
TreeView oder doch was anderes?
Re: TreeView oder doch was anderes?
Keine Ahnung, wieviele Pages du benötigst. Wenn es eine übersichtliche Zahl ist (die Reiter der Pages auf eine Seite passen), finde ich ein TPageControl immer eine schöne Lösung. Sobald man scrollen muss, sollte mMn die Zahl der Pages reduziert werden. Evtl. wäre dann ein TreeView zum Anzeigen der Pages einsetzbar (dann würde ich ein TTreeView kombiniert mit einem TNoteBook nehmen, ähnlich der Lazarus IDE Options).
Ein TreeView zum bearbeiten von Einträgen würde ich nur nehmen, wenn die Eingaben (Notes) gleichwertig sind. Sowas habe ich zum Beispiel in einem AVA Programm gemacht (mit VirtualStringTree). Ist dort eine recht schöne Lösung.
Ein TreeView zum bearbeiten von Einträgen würde ich nur nehmen, wenn die Eingaben (Notes) gleichwertig sind. Sowas habe ich zum Beispiel in einem AVA Programm gemacht (mit VirtualStringTree). Ist dort eine recht schöne Lösung.
Code: Alles auswählen
type
TLiveSelection = (lsMoney, lsChilds, lsTime);
TLive = Array[0..1] of TLiveSelection;
Re: TreeView oder doch was anderes?
Ich hatte schon öfter Treeviews mit einem Pagecontrol kombiniert, wobei zu jedem TreeNode ein Tab des PageControls gehört. Die Zuordnung, welcher Node zu welchem Tab gehört, kann man im Tab-Property der Nodes bzw. Tabs festlegen, so dass man beim Anwählen eines bestimmten Nodes den zugehörigen Tab anzeigen kann. Wenn man die Tabs mit TabVisible ausblendet, sieht man von dem PageControl nichts mehr. In Linux (ich glaube gtk2) hat das aber den Nachteil, dass mit TabVisible := false auch der Inhalt der Seite verschwindet... Daher ist,wie von Michl angesprochen, ein TNotebook geeigneter, allerdings im Designmode nicht mehr so bequem zu bedienen. Gerade wenn es sehr viele Nodes sind, bietet sich daher auch an, die Controls, die zu jedem Node gehören, gleich in einem TFrame, also in einer separaten Unit, zu designen und die Frame dann im OnSelect des TreeViews ins Formular zu holen.
-
- Beiträge: 6079
- Registriert: Do 21. Sep 2006, 07:51
- OS, Lazarus, FPC: iWinux (L 1.x.xy FPC 2.y.z)
- CPU-Target: AVR,ARM,x86(-64)
- Wohnort: Dessau
- Kontaktdaten:
Re: TreeView oder doch was anderes?
Zur "Übersichtlichen Zahl" kann ich noch was beitragen. 7 !!!
Das ist das was ein Mensch ohne Stress auf einen Blick erfassen kann.
Man sollte also vermeiden immer mehr als 7 Einträge in Menüs,Tabs,u.s.w. einzusetzen darüber sinkt die Usability.
Das ist das was ein Mensch ohne Stress auf einen Blick erfassen kann.
Man sollte also vermeiden immer mehr als 7 Einträge in Menüs,Tabs,u.s.w. einzusetzen darüber sinkt die Usability.
W.m.k.A.h.e.m.F.h. -> http://www.gidf.de/
- photor
- Beiträge: 443
- Registriert: Mo 24. Jan 2011, 21:38
- OS, Lazarus, FPC: Arch Linux: L 2.2.6 FPC 3.2.2 (Gtk2)
- CPU-Target: 64Bit
Re: TreeView oder doch was anderes?
Moin,
Danke erstmal für Euren Input. Ich werde weiter probieren.
In meinem Test-und-Probier-Hobby-Project sind es 5 Tabs. Das ist noch recht übersichtlich. Ist ja aber auch nur zum Testen der Konzepte.
Im Firmenprojekt sind es dann schon ca. 10 (bis jetzt) mit zum Teil sehr vielen Parametern (bis 20), die man am liebsten noch weiter unterteilen würde. Bloß jetzt noch wiederTabs auf den Tabs unterzubringen würde der Übersichtlichkeit auch nicht helfen. Daher bin ich ja auf den Baum gekommen (den man eventuell ein- und ausklappen kann. Viele der Parameter werden bisher auf verschiedenen Popups eingegeben; da kann man schonmal einen (vielleicht wichtigen Schalter/Parameter aus dem Auge verlieren (das "Design" ist nunmal so in den letzten 10 Jahren gewachsen ).
Ciao,
Photor
Danke erstmal für Euren Input. Ich werde weiter probieren.
In meinem Test-und-Probier-Hobby-Project sind es 5 Tabs. Das ist noch recht übersichtlich. Ist ja aber auch nur zum Testen der Konzepte.
Im Firmenprojekt sind es dann schon ca. 10 (bis jetzt) mit zum Teil sehr vielen Parametern (bis 20), die man am liebsten noch weiter unterteilen würde. Bloß jetzt noch wiederTabs auf den Tabs unterzubringen würde der Übersichtlichkeit auch nicht helfen. Daher bin ich ja auf den Baum gekommen (den man eventuell ein- und ausklappen kann. Viele der Parameter werden bisher auf verschiedenen Popups eingegeben; da kann man schonmal einen (vielleicht wichtigen Schalter/Parameter aus dem Auge verlieren (das "Design" ist nunmal so in den letzten 10 Jahren gewachsen ).
Ciao,
Photor
Re: TreeView oder doch was anderes?
Ich glaube, ich habe nicht verstanden, was du erreichen willst. Kannst du nich dein Hobby-Projekt posten? (Bitte alles unnötige entfernen, hier will keiner 1000 Zeilen Code durchsuchen. Und bitte nur pas, lfm, lpi und lpr-Dateien zusammen in einem gemeinsamen zip, keine vom Compiler erzeugten Dateien).
-
- Beiträge: 2013
- Registriert: Do 16. Okt 2008, 10:22
- OS, Lazarus, FPC: Linux,Windows,FreeBSD,(MSEide+MSEgui 4.6,git master FPC 3.0.4,fixes_3_0)
- CPU-Target: x86,x64,ARM
photor hat geschrieben:Im Firmenprojekt sind es dann schon ca. 10 (bis jetzt) mit zum Teil sehr vielen Parametern (bis 20), die man am liebsten noch weiter unterteilen würde. Bloß jetzt noch wiederTabs auf den Tabs unterzubringen würde der Übersichtlichkeit auch nicht helfen.
In MSEide verwende ich für die Einstellung aller Projekt-Optionen Tabs-in-Tabs, hat sich bewährt. Falls du probieren willst wie es sich anfühlt: 'Project'-'Options'.
Die zuletzt gewählte Tabs weren zwischen den Sitzungen gespeichert, so dass man eine unterbrochene Arbeit einfach fortsetzen kann.
Für Pflichtfelder, welche nicht vergessen werden dürfen, ist die oe_notnull Option in den OptionsEdit Properties der Edit-Widgets gedacht.
Oder man macht geführte Eingabe-Dialog-Ketten. Persönlich mag ich letztere für häufig genutzte Eingaben weniger, da sie den Arbeitsablauf einschränken.