8. Okt 2010 

lieber auf deutsch lesen

Hierarchical lists are both a valuable interface-object and a data-container. Up to V11, we had 255 characters and a longint. But then 4D opened the storage capacity of hierarchical lists by adding a LIST ITEM PARAMETER. What is that good for?

As most of the times, the manuals define what is possible and sometimes formulate what we should not do. Missing much to often are those hints, that explain to the non-professional why this option is added.

Do you understand what this means?
Custom selector: You can also pass custom text and associate it with a value of the Text, Number or Boolean type in selector. This value will be stored with the list item and may be retrieved using the GET LIST ITEM PARAMETER command. This lets you set up any type of interface associated with hierarchical lists. For example, in a list of customer names, you can store the age of each person and only display it when the corresponding item is selected.

I love the feature, because now I can store all extra-information inside the hierarchical list, where it belongs, instead of keeping track in a seperate datastructure like records or a couple of arrays.

You ask, why I want to store extra-information inside a listbox? One important usage of hierarchical lists are navigational lists like those in the DBZ-component. In a basic hierarchical list I'd store the tablename in listitemtext and the tablenumber in listitemref. For navigational purposes I need to have a inputform attached to every listitem, to open an inputform on doubleclick. That means keeping track in an invisible ARRAY TEXT(t_Inputform) and an invisible ARRAY LONGINT(t_TableNbr).

Now when doubleclicking I need to Find in array(t_TableNbr;$listitemref) and check wether the found line is valid. If the foundline is valid then set INPUT FORM (t_Inputform{$foundLine}).

Utilizing LIST ITEM PARAMETER keeping track of extra data gets easier: when creating the list I SET LIST ITEM PARAMETER (list;$itemRef;"inputform";"myNiceMainEditor"). When doubleclicking I use the reverse command GET LIST ITEM PARAMETER (list;$itemRef;"inputform";$useInputForm). $useInputForm will contain "myNiceMainEditor" so I set INPUT FORM($useInputForm).

Best of all: saving hierarchical lists saves the parameters too, both into the Toolbox lists and LIST TO BLOB.

Hurray, great enhancement to the 4D language!

While new to the command; I'll use it like this
SET LIST ITEM PARAMETER (list;$itemRef;"inputform";"myNiceMainEditor"). Some days later I'm thinking about not to use text for the selector, instead using something like
MySelector_Mngr ("SelectorName_Get";"Inputform") where MySelector_Mngr behaves similar to Get localized string.

Then I discover, the command GET LIST ITEM PARAMETER SELECTORNAMES is missing. Holy moly, I've to keep track of used selectors myself.

But now, I'm cured of hidden datastructures to keep track of additional information concerning hierarchical lists. I'll keep them inside the list themselve. I need to wrap the SET LIST ITEM PARAMETER and GET LIST ITEM PARAMETER into a method of my own. The aim is to keep one additional parameter, that keeps track of the used parameter-names. That's 150 lines of code including lots of error-prevention and defensive coding.

Now I use HierList_Parameter ("Add";$hl_Sprachen;0;"english";->$interText) to add a Parameter to the list and retrieve the parameter this way HierList_Parameter ("Get";$hl_Sprachen;0;"english";->$interText).

Additionally HierList_Parameter ("ParameterArrays_Get";hl_Files;0;"";->$t_ParamName;->$t_Paramvalue) gives me all parameters and their accompanying values back. This is especially useful, when transforming XML into hierachical lists and storing the attributes as LIST ITEM PARAMETER, where the attributename serves as selectorname and the attributevalue as parametervalue.

As most of the time: if 4D doesn't support a feature, I can build it myself. And there might be additional benefits for the work I had to invest.

By the way, there is one special parameter Additional text. 4D handles that and displays the content of the Additional text right-aligned. These days of unicody there is a lot of symbols and signs to display the additional text iconic. If only the method-editor would support unicode.
There is a workaround too. Store the symbolic characters in an Xliff-file. Use Get localized string to populate the parameter-value from this Xliff-file.

You want to have the source-code? No problem! Send a descend amount of $ or € to my PayPal-account: info@mettre.de. Finding out how much?