TreeView oder doch was anderes?

Für allgemeine Fragen zur Programmierung, welche nicht! direkt mit Lazarus zu tun haben.
Antworten
Benutzeravatar
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

TreeView oder doch was anderes?

Beitrag von photor »

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.

Michl
Beiträge: 2505
Registriert: Di 19. Jun 2012, 12:54

Re: TreeView oder doch was anderes?

Beitrag von Michl »

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.

Code: Alles auswählen

type
  TLiveSelection = (lsMoney, lsChilds, lsTime);
  TLive = Array[0..1] of TLiveSelection; 

wp_xyz
Beiträge: 4869
Registriert: Fr 8. Apr 2011, 09:01

Re: TreeView oder doch was anderes?

Beitrag von wp_xyz »

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.

Christian
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?

Beitrag von Christian »

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.
W.m.k.A.h.e.m.F.h. -> http://www.gidf.de/

Benutzeravatar
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?

Beitrag von photor »

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

wp_xyz
Beiträge: 4869
Registriert: Fr 8. Apr 2011, 09:01

Re: TreeView oder doch was anderes?

Beitrag von wp_xyz »

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).

mse
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

Beitrag von mse »

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.
Dateianhänge
options.png

Antworten