Jump to content


Photo
- - - - -

[CR] Tree Control API


  • Please log in to reply
15 replies to this topic

#1 Norm Kirchner

Norm Kirchner

    The 500 club

  • NI
  • 747 posts
  • Location:Austin, TX
  • Version:LabVIEW 2012
  • Since:2000

Posted 03 July 2009 - 12:11 AM

*
POPULAR

Posted Image

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
  • dannyt, jcarmody and zhengchenglin like this

#2 ElijahKerry

ElijahKerry

    Active

  • Members
  • Pip
  • 12 posts

Posted 06 March 2010 - 07:29 AM

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

#3 Antoine Châlons

Antoine Châlons

    The 500 club

  • Members
  • PipPipPipPipPip
  • 614 posts
  • Version:LabVIEW 2012
  • Since:1999

Posted 07 March 2010 - 12:34 PM

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!

TiTou.png


#4 Daklu

Daklu

    Bringing the Fu to you

  • Premium Member
  • 1,830 posts
  • Location:Seattle
  • Version:LabVIEW 2009
  • Since:2006

Posted 09 March 2010 - 06:41 AM

*
POPULAR

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.)

Attached Files


Edited by Daklu, 09 March 2010 - 06:42 AM.

  • Norm Kirchner, Antoine Châlons and jcarmody like this

Certified LabVIEW Architect
Dak's First Law of Problem Solving: If the solution looks simple, I don't know enough about the problem.

Yes, the QSM is flexible. So is Jello. That doesn't make it good construction material.

There are two secrets to success:
Secret #1 - Never tell everything you know.


#5 dannyt

dannyt

    Extremely Active

  • Premium Member
  • 396 posts
  • Location:Devon UK
  • Version:LabVIEW 2011
  • Since:2007

Posted 29 April 2010 - 08:49 AM

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.

Attached File  Tree Expand Item.vi   15.8KB   306 downloads

Edited by dannyt, 29 April 2010 - 09:19 AM.


#6 dannyt

dannyt

    Extremely Active

  • Premium Member
  • 396 posts
  • Location:Devon UK
  • Version:LabVIEW 2011
  • Since:2007

Posted 29 April 2010 - 11:02 AM

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.

Attached File  Item Modify Cell Color.vi   21.96KB   270 downloads

#7 dannyt

dannyt

    Extremely Active

  • Premium Member
  • 396 posts
  • Location:Devon UK
  • Version:LabVIEW 2011
  • Since:2007

Posted 06 May 2010 - 09:16 AM

Hi Norm

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

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

#8 jgcode

jgcode

    LabVIEW Renegade

  • OpenG
  • PipPipPipPipPipPip
  • 2,407 posts
  • Location:Australia
  • Version:LabVIEW 2009
  • Since:2005

Posted 06 May 2010 - 02:51 PM

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

#9 loserboy

loserboy

    Active

  • Members
  • Pip
  • 14 posts
  • Location:South Carolina
  • Version:LabVIEW 8.5
  • Since:2008

Posted 24 September 2010 - 06:20 PM

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?

#10 candidus

candidus

    Very Active

  • Members
  • PipPipPip
  • 82 posts
  • Version:LabVIEW 2010
  • Since:2002

Posted 03 January 2012 - 02:58 PM

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...

#11 asbo

asbo

    I have no idea what you're talking about... so:

  • V I Engineering, Inc.
  • 1,273 posts
  • Version:LabVIEW 2011
  • Since:2008

Posted 03 January 2012 - 03:59 PM

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.

#12 jgcode

jgcode

    LabVIEW Renegade

  • OpenG
  • PipPipPipPipPipPip
  • 2,407 posts
  • Location:Australia
  • Version:LabVIEW 2009
  • Since:2005

Posted 04 January 2012 - 02:07 AM

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. :)

#13 candidus

candidus

    Very Active

  • Members
  • PipPipPip
  • 82 posts
  • Version:LabVIEW 2010
  • Since:2002

Posted 04 January 2012 - 04:06 PM

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... :(

#14 asbo

asbo

    I have no idea what you're talking about... so:

  • V I Engineering, Inc.
  • 1,273 posts
  • Version:LabVIEW 2011
  • Since:2008

Posted 04 January 2012 - 07:54 PM

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

#15 jgcode

jgcode

    LabVIEW Renegade

  • OpenG
  • PipPipPipPipPipPip
  • 2,407 posts
  • Location:Australia
  • Version:LabVIEW 2009
  • Since:2005

Posted 05 January 2012 - 09:57 AM

*
POPULAR

I reckon this package would make a great OpenG candidate.
  • dannyt and Fab like this

#16 dannyt

dannyt

    Extremely Active

  • Premium Member
  • 396 posts
  • Location:Devon UK
  • Version:LabVIEW 2011
  • Since:2007

Posted 05 January 2012 - 11:37 AM

I reckon this package would make a great OpenG candidate.


indeed it would