english preferred

Ich hatte mir hierarchische Listen mit variabler Anzahl von Spalten gewünscht. Es wurden hierarchische Listboxen. Das sind immer Array-Listboxen, also gut zu organisieren und zu nutzen.

Ich behandle Listboxen wie ein Widget, eine zusammenhängende Einheit, keine Gedanke mehr an die einzelnen Arrays. Kein Code an einem Element einer Listbox. Die Listbox ruft ihre Manager-Methode auf, sonst nichts. Die Listbox bekommt von mir keinen Variablennamen, nur noch einen Objektnamen.

Listbox-Hierarchien einstellen

Das Einstellen über die Eigenschaften-Liste ist mir zu trocken. Erst die Hierarchie per Checkbox aktivieren und anschließend die Namen der Arrays in der gewünschten Reihenfolge eintragen. Bewährt sich die angedachte Reihenfolge nicht, schreibe ich das neu. Nee, viel zu umständlich.

Ich ziehe vor, mir die Listbox zu malen. Zuerst werden alle Spalten im Formular-Editor angelegt. Die ersten 1, 2, 3 Spalten ergeben die Hierarchie. Die wähle ich aus und erzeuge über die rechte Maustaste, bzw. den Doppelfinger-Klick auf dem Trackpad, die Hierarchie.

Bewährt sich die erste Version nicht – mehr als eine Hierarchie-Ebene erfordert viel Probieren –, wähle ich die Hierarchie-Spalten erneut aus und lösche über die rechte Maustaste die Hierarchie. Jetzt bewege ich die Spalten über Drücken-und-Halten des Spaltenkopfes in die neue Position. Anschließend lege ich die Hierarchie neu an.

Das ist die schnellere und übersichtlichere Vorgehensweise.

Pseudo-Hierarchien

Ich benutze die hierarchische Listbox auch um Hierarchien in Listen unterzubringen, die eigentlich keine Hierarchie haben. Dabei kommt mir zugute, daß die Zeilenbreite der Hierarchie-Ebene über die gesamte Breite der Listbox reicht. In der ersten Spalte setze ich den Text so, daß er gut sortiert und strukturiert.

Mit 4D-Code umbauen

Manchmal sind mit den gleichen Daten unterschiedliche Hierarchien notwendig. Einmal nach Hersteller  und Produkt, die andere Version nach Preisgruppe, die dritte ganz ohne Hierarchie. Immer sind es die gleichen Daten, nur unterschiedliche Spaltenfolgen und dazu passenden Hierarchien.

Die 4D-Befehle sind da

• LISTBOX GET ARRAYS
• LISTBOX MOVE COLUMN
• LISTBOX INSERT COLUMN
• LISTBOX GET HIERARCHY und
• LISTBOX SET HIERARCHY

Das sieht nicht nur nach viel Arbeit aus, so ist es auch. Bis der Code funktioniert, vergeht ein Tag oder zwei. Dann kommt der Kunde und braucht es wieder anders, …

Mit Formular-Objekten jonglieren

4D unterscheidet schon länger nach dem Variablen-Namen und dem Objektnamen für jedess Formular-Object. Die Variablen-Namen geben Zugriff auf den Speicherplatz. Die Objekt-Namen stehen für die Instanz im Formular und sind eindeutig im Formular. Dieser Unterschied zw. Variable und Objekt bietet mir die Gelegenheit Formular-Varianten der Listbox zu gestalten, statt sie per 4D-Code zu berechnen. Leichter zu warten ist das auch.

Auf Code-Ebene fülle ich alle Arrays in einem Rutsch. Das heißt SELECTION TO ARRAY und danach in einer For-Schleife alle zu berechnenden Arrays. Zu den zu berechnenden Arrays gehören häufig die Arrays der Hierarchien. Bis einige tausend Zeilen ist die Performance mehr als hinreichend, trotz der For-Schleife.

Im Formular habe ich mehrere Listboxen, alle mit eigenem Objektnamen und denselben Arrays. Die Listboxen unterscheiden sich in der

• Reihenfolge der Spalten
• den Hierarchien
• graphischen Eigenschaften wie Schrift und Farben
• sichtbar, nicht sichtbar
• eingebbar und nicht eingebbar.

In diesem Screenshot sind 3 Varianten einer Darstellung zu sehen

• Listbox to be filled by code (z.B. SQL-Select into Listbox)
• Non-hierarchical Listbox und
• Hierarchical Listbox

Je nach Situation wird eine der Listboxen mit ihrem Objektnamen in den sichtbaren Bereich auf das Rechteck mit Namen „payload“ bewegt, die beiden anderen werden über ihren Objektnamen auf das Rechteck mit dem Namen „parking“ außerhalb des sichtbaren Bereiches verschoben. Dazu dient der Befehl OBJECT MOVE. Die beiden Rechtecke „payload“ und „parking“ sind unsichtbar. Ich brauche diese Rechtecke, weil sie sich bewegen und wachsen und mir so die tatsächlichen Koordinaten liefern.

Außerdem

• die gelb-gestreiften Zebra-Spalten sind die nicht-sichtbaren Spalten. Das Häßliche hilft mir in der Gestaltung.
• ich könnte die Listboxen sichtbar/unsichtbar schalten, statt sie zu bewegen. Dann blitzt ab und an ein Rollbalken durch, was stört.
• Formular-Objekte brauchen keinen Variablen-Namen. Den vergibt 4D zur Laufzeit. Einer Listbox gebe ich keinen Variablennamen, die Objektnamen der Arrays sind mir meistens unwichtig.

lieber auf deutsch

I love hierarchical listboxes as a matter of UI. Hierarchical listboxes are always array-listboxes, which means easy to handle and act on. I’d prefer hierarchical list with a variable count of columns, but making the best with the tools you have is mostly a good advice.

Listbox-Properties

Setting listbox-hierarchies by property-list is no fun. First check for the hierarchie and then enter the names of the arrays belonging to the hierarchy in the proper way. Use copy&paste or debug for wrong spelling or debug for copy&paste-erros. If the thought-of sequence doesn’t work out, you start over again. No, that doesn’t sound nice and indeed, it isn’t.

I love to draw my listboxes. Starting with entering the array-variables in a proper order, define data-type and formates where necessary. The first 1-2-3 columns will be used for the hierarchies. I select those with right-mouse-button-click, double-finger-click on trackpad accordingly, and create the hierarchy.

If this first version doesn’t work – more than one level of hierarchy calls for trial and error –, I clear the Hierarchie via right-mouse-click. Then I rearrange by dragging the column-header around. Finally a new hierarchy is created of the first column(s).

I like that way of working a lot better for being faster and more obvious.

Pseudo-hierarchies

There are situations where there is no hierarchy within the data. That flat-list is just a mess. In that case I appreciate the hierarchical-cell being as wide as the whole listbox. The first column gets filled with text that sorts and structures properly, even when the content is already viewable in one of the columns.

Use 4D-Code to reorganize

Sometimes I need different displays for the same data. Different hierarchies, one sorted by supplier and product, another one sorted by price-category, and a third without any hierarchy.

The 4D-commands are available

• LISTBOX GET ARRAYS
• LISTBOX MOVE COLUMN
• LISTBOX INSERT COLUMN
• LISTBOX GET HIERARCHY and
• LISTBOX SET HIERARCHY

That looks like a lot of work and it is. It’ll take a day or two to get the code running. Then the customer needs a different layout, …

Working with form-objects

For quite some time 4D differentiates between variable-name and the object-name. The variable-name is the name of the arrays. The listbox and each of the arrays do have a distinct object-name. The variable-names give access to the storage in memory, the object-name accesses the instance on the form. The difference between variable and object opens the door to draw the listbox-variants instead of writing some algorithm. Maintenance is less efforts, too,

By code I fill the arrays in a single statement. Which means SELECTION TO ARRAY followed by a For-loop to fill calculated array-cells. Some of the calculated ones are the cell-contents needed to build the hierarchy. Up to a couple thousand rows, there is no performance-hit for that extra loop.

In my form I do have a couple of listboxes. All with different object-names but containing the same arrays. Those list boxes are different concerning

• order of columns
• columns included in hierarchies
• graphically like fonts and colours
• visible, non-visible
• enterable, non-enterable.

This screenshot shows three list boxes with same content but different displays

• Listbox to be filled by code (e.g. SQL-Select into listbox)
• Non-hierarchical listbox and
• hierarchical Listbox

Depending on situation one of the listboxes is moved by its object-name onto the rectangle with name „payload“, both of the others are moved by their object-names onto the rectangle named „parking“ beyond the visible area of the form. I use the command OBJECT MOVE. Both rectangles „payload“ and „parking“ are invisible. I need those rectangle, they move and grow when resizing and deliver the real coordinates during runtime.

To be mentioned

• the yellow-zebra-columns are the invisible ones. While building the form, it helps to know.
• instead of moving objects I could toggle between visible/unvisible. That’s not a good idea because of scrollbars flashing
• form-objects don’t need a variable-name. 4D will set one in runtime. I never set the variable-name of a listbox, I mostly don’t care about the object-name of the listbox-arrays.