LabVIEW
Tree control alphabetic elements?
Solved!
Hi,
I need to build a tree from a list of variables. I have found the treemap pallette which works great and I was able to construct my table pretty quickly.
The issue I have is that the elements are sorted in an alphabetic order including the items with subelements. This looks awkward as normally I'd expect items with subitems at the top of the list, just as for example the windows explorer puts folders above the files (in most cases).
So for example under "global" I'd expect phone to be the topmost item, but instead I get "mybool" and "parent" in front of it. I assume its because this pallette uses sets and I guess that puts the items in alphabetical order, but not sure.
Is there a way / settings / config etc to achive the look I'd like to have?
thanks!
1) with the reference of the tree (after the lib populated it), recurse the tree. If an item is a parent, move it after the previous parent and step into it to move it's children it they're parents.
2) modify (a copy of) the library
1) is tricky, but leaves the library untouched.
2) is more performant but might also be tricky (depending on how it's written)
Search LabVIEW like a graph! Something like this (see attached VI)
The sub VI is the VI itself (it's reentrant).
Call like this:
You might want to hide the tree before populating and after it's done. Of turn defer panel off and on after. Populating trees (and listboxes) can take forever if each change updates the screen.
Yeah it seems that once the tree is created with the lib then I still need to postprocess it. I'm wondering that there is no option to achive what I need cause I think that representation is the most wanted.
The VI you attached simply flattens the hierarchy by moving all "subfolders" to the root. I could generate the hierarchy like that quite easily. I spent about 2 hours of my life writing a routine which creates the hiearchy and I'd like to keep it. I just need that "subfolders" to be at the top of their own "folder"
Of course its possible that I somehow misused your VI. I just connected the tree reference to its input and called it after my tree was generated
@1984 wrote:Of course its possible that I somehow misused your VI. I just connected the tree reference to its input and called it after my tree was generated
No, I just didn't test is very well.
I don't think it needs much work.
All that's wrong is that the move moves the parent to the root, not the current.
I assumed leaving the new parent open would move it to the current parent, but it moves to the root.
An easy fix, although there might be more bugs:
@1984 wrote:
I'm wondering that there is no option to achive what I need cause I think that representation is the most wanted.
Copy the library and modify it...
Better yet. Redesign the library so it's OO and provide overwrite methods to make any user of the library specify the behavior. 😁
The tree has no "put parent items on top" options. I agree that sounds like a 'nice to have' option. But it should definitely be an option, not the standard behavior. If the tree has sequential steps, and steps can have sub steps, I want the parent items in the order I (or the user) put them in, not on top:
