[CR] Tree Control API

[Norm Kirchner]

Name: Tree Control API

Submitter: Norm Kirchner

Submitted: 02 Jul 2009

File Updated: 03 Jan 2011

Category: User Interface

LabVIEW Version: 8.2

License Type: BSD (Most common)

Copyright © 2007, Norman J. Kirchner, Jr.

All rights reserved.

Norman J. Kirchner, Jr.

Author:

Norman J. Kirchner, Jr

--see readme file for contact information

Description:

Package to provide smart tree functionality without assumption of type of data (ie, file paths or others)

Gives ability to modify contents, extract information and control the branches.

A good understanding of how the LV tree truly operates as a fancy multi-column listbox is very useful although not required.

An expample program if not present on the forums, will be in place soon.

Dependancies:

LV version above base package

Functions

Add Item

Modify Item

Remove Item

Get All Items

Get Top Level Items

Get Items Parent

Get Selected Item

Get Siblings

Get Children

Get Item Properties

Check Tag Valid

Convert Tag to Text

Find Tag from Text

Outdent at Item

Indent At Item

Expand

Collapse

Empty Tree

Notes

Capable of working w/ LV 7 or later but uploaded version is for LV 8.2. Please request previous version if necessary.

Good to recognize that the tree control is just a fancy multi-column listbox.

Version

1.0.0 Initial Release

1.0.1 Example program added

Click here to download this file

[ElijahKerry]

This API looks like it could be really useful! I'm a big advocate of making a package for VIPM :-)

[Antoine Chalons]

This API looks like it could be really useful! I'm a big advocate of making a package for VIPM :-)

I totally agree, one more vote for a VIPM package!

[Daklu]

This API looks like it could be really useful! I'm a big advocate of making a package for VIPM :-)

I totally agree, one more vote for a VIPM package!

Okie... try this. The palette is in User Library -> LavaCR. Code is in vi.lib\addons\_LavaCR\Tree Control API.

(The original Library is in 8.2. I had to recompile to 8.6.)

lava_lib_tree_control_api-1.0.1-1.vip

Edited March 9, 2010 by Daklu

[dannyt]

Hi I would just like to say I have only started working with LabVIEW tree's for about a week now. I have found this API to be a really great place to start would highly recommend it to anybody. So from me much Kudos and thanks to Norm.

cheers Dannyt

PS I do not know if you want to add this VI to it next time you up-issue.

Tree Expand Item.vi

Edited April 29, 2010 by dannyt

[dannyt]

HI

I notice that with most of these VI you have allow the caller to pass in the tree reference or use the internal get current VI to find it, you use the same approach for the item tags.

Other than the consideration of "data flow" is there any rewason to favour one method over the other, ie pass things round or leave the VI to figure it for themselves ?

cheers

Dannyt

Another option to add to API.

Item Modify Cell Color.vi

[dannyt]

Hi Norm

I have found this API SO useful over the last week so much Kudos to you sir .

Can I just ask a couple more questions.

Why all these VI's are Reentrent ? Is there a fundamental reason for this or just your choice. I am just trying to increase my understanding.

I can understand that "Get All.VI" needs to be as you do a recursive call on it, but I do not really understand why all the other are. In fact I wonder if you really want things like Item Add.vi to be reentrent.

Along the same lines I assume that Debugging is disabled because the VI's are Reentrent ?

Finally in the "Get All.vi" which is Reenternet I noticed it calls the "Merge Errors.vi" which is itself not Reentrent, should this really be replaced ?

cheers

Dannyt

[jgcode]

Why all these VI's are Reentrent ? Is there a fundamental reason for this or just your choice. I am just trying to increase my understanding.

I can understand that "Get All.VI" needs to be as you do a recursive call on it, but I do not really understand why all the other are. In fact I wonder if you really want things like Item Add.vi to be reentrent.

Along the same lines I assume that Debugging is disabled because the VI's are Reentrent ?

Finally in the "Get All.vi" which is Reenternet I noticed it calls the "Merge Errors.vi" which is itself not Reentrent, should this really be replaced ?

Hi Dannyt

I can't speak for Norm's choices but you can use reentrency to create non-blocking VIs which means if that subVI is used in lots of places, they won't effect each other. This is the choice I made when designing my reuse library, I was under the impression this was common.

As it turns out recently others have voiced against this - saying even NI subVIs aren't reentrent e.g. Merge Errors would be a bottle neck (as a side note Darren has pointed out the poor performance of this VI in a nugget and there is an update for 2010 as shown in the Idea Exchange Forum.)

Anyways here is some more discussion on the subject.

Here AQ talks about the algorithm used for shared clones.

Enjoy!

Cheers

-JG

[loserboy]

Thanks Norm for this awesome toolkit! after downloading your version here, and doing a beyond compare with a version i already have, there seems to be a Tree Control Toolkit V1.0.2 floating around somewhere that i downloaded? Where did i pick this 1.0.2 version up?

[candidus]

Thanks, this API is great!

But I have a perhaps rather stupid question: Are there any resons why is a new sibling inserted before existing siblings and not after them? After would seem more logically to me...

[asbo]

But I have a perhaps rather stupid question: Are there any resons why is a new sibling inserted before existing siblings and not after them? After would seem more logically to me...

I believe this is simply NI standard. For example, if you right-click an array, under the Data Operations menu, you get the choice Insert Element Before. Similarly, in the Edit Items property pane of a Ring control, the Insert button adds an item before the currently selected item. I agree it's not very intuitive, but it's something you grow accustomed to. You could probably wrap the Item Add VI to correct this without much trouble.

[jgcode]

Are there any resons why is a new sibling inserted before existing siblings and not after them? After would seem more logically to me...

I agree - comparing this to e.g. traversing/working with the DOM; you have an appendChild() method which adds the element to the end of the parent's existing child nodes, and when position is important you have insertBefore() method.

...but it's something you grow accustomed to.

But I also agree with this - it's definitely something you get used to / don't even think about too much after using LabVIEW for a while.

[candidus]

Thank you, I understand better now. But even the "Edit Tree Items.Add Item" method of the LV tree control has an input to specify "Child Position". I wonder why it is unused in this Tree Control API. I would create a derived class to override the default behavior but unfortunately that is impossible: The necessary properties aren't exposed in the API. Seems that I have to modify the classes and maintain my own copy...

[asbo]

If you make your change backward compatible, get a hold of Norm and see if he'll incorporate it into the package.

[jgcode]

I reckon this package would make a great OpenG candidate.

[dannyt]

I reckon this package would make a great OpenG candidate.

indeed it would

[Ulf]

Which license type do you use in version 1.0.1? BSD or LGPL? The "Readme"-file states that version 1.0.0 use LGPL and this support page says that version 1.0.1 is under BSD.