LiveCode Forums

I have been looking at the Tree-View widget as a possible way of displaying a table of contents.
Initially I couldn't see how this was possible as whenever I played around with the widget and entered a sub element into the tree, the data of the parent node would disappear.
I then realised that the widget displayed the keys to the underlying array, but only the values for the deepest keys.
I could work with this (not have anything in the values) except this meant the keys needed to be shown in some order (numerical or alphabetical) which wouldn't work for me as the entries in my table of contents were not alphabetical nor numeric in the order.

At the last LC Global Elenor presented a talk on using the widget as the basis of a menu.
In that talk she presented the following slide.
As you can see, the widget view she intends to convert to a menu has its elements UNSORTED.
They are not alphabetical.

While playing with a tree view widget's PI I was able to enter values out of order, so to speak, but I don't know how or why they would then not sort!
But when constructing an array to be displayed by the widget via script, the sorting took effect and I could not get an unsorted display.

So it seems an unsorted hierarchical list, as shown above, really can be displayed by the tree view widget (but I am unsure as to how one determines the order.)

QUESTION:
How can the underlying array for such an unsorted hierarchical list be constricted via script?

Hi James,

EDIT: I thought I could find a way but did not succeed.

Kind regards
Bernd

Thanks for giving it a go Bernd.

To do this would require a pretty significant change to the widget. The underlying data is an array so the value is either a string or an array. Keys are sorted alpha or numeric. You could probably use 2 part keys (sort ID,key name) and adjust the code to sort by the ID and display the key name.

I’ll need to dig up the LCG code to see how that was done.

I am beginning to think the slide was a fudge. Perhaps I need to go through the presentation to see if there is a clue.

Mmmm, fudge...

James,

I don't think the slide was a fudge but it was from a version that was more advanced than what was covered in the video. Elanor did say that she wanted to put the modified version up on the extension store once it is finished. And for a menulist, that is how she called the modified version, a alphabetically sorted list would not make much sense.
I found the video very useful in how Elanor approached modifying a complex widget like the tree view.

Kind regards
Bernd

Thanks for that Bernd. I will go through the session.
The thought of having the tree display the array elements and not the keys has got me thinking.
But first I need to understand the current widget more.

Okay, I gave it another try:

This is a horrible hack
I take a list of what I want to display as a "menuList" i.e. a list that keeps the original order of the list.

The problem in just passing this list as an array with the lines of the list as keys is that arrays beyond 9 keys are not ordered. TreeView does an alphabetic ordering on non-numerical keys, but in this special case the simple alphabetic ordering is not what you were after.

I resorted to prepend the lines of the list with invisible characters from the below ASCII 32 region. Now that determines the text sorting of the keys but the keys look like before when displayed.

That implies that all keys returned from the treeView is "dirty" i.e. with the invisible chars prepended. There is a cleanUp function in the script of the treeView.
(Last char in prefix is ASCII 31, I set the itemDelimiter to get item -1)

On the other hand you need the "dirty" keys to work on the array. Changing the hilite or double-clicking reports both the dirty and the clean keys in the stack.

The hack is currently limited to roughly 600 lines (this is not checked for)

I did not test all error conditions, so if you want to use this (and I am not sure one should) be careful and test it extensively.

Works with the run of the mill treeView widget, tested in LC 9.0

Kind regards
Bernd

Edit: the text of this post applies also to the stack I posted in the next post which is just a cleaned up version of the one I posted here previously.

here is a cleaned up version of the first stack I posted.
Additionally there was a small glitch in there too.

Kind regards
Bernd

I now realise that the issue I was trying to solve is an inherent part of arrays as implemented in LC.
It appears that for any key in an array, if another dimension is added to that key, the value of that key becomes an array thus losing whatever non array value it had.
Thus when you add a sub level you wipe the prevoius value out.
This means to solve my problem using a tree widget I would need to...
1. Display the values not the keys, and
2. Have every element in the tree a member of one array where each has the same number of dimensions.

So instead of
A[1]
A[2][1]
A[2][2]
A[3]

I would require
A[1][1]
A[2][1]
A[2][2]
A[3][1]

Which would then require a much more extensive change to the widget internals.
Certainly constructing the array via script is simple, but via the property inspector not so easy unless you required the number of levels to be entered first.
All this is doable, but maybe not worth the effort.