Jump to content
Norm Kirchner

[CR] Tree Control API

Recommended Posts

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!

Share this post


Link to post
Share on other sites

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 by dannyt

Share this post


Link to post
Share on other sites

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

Share this post


Link to post
Share on other sites

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

Share this post


Link to post
Share on other sites

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

Share this post


Link to post
Share on other sites

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?

Share this post


Link to post
Share on other sites

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

Share this post


Link to post
Share on other sites

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.

Share this post


Link to post
Share on other sites
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. :)

Share this post


Link to post
Share on other sites

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

Share this post


Link to post
Share on other sites

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

Share this post


Link to post
Share on other sites

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.

Share this post


Link to post
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.


×
×
  • Create New...

Important Information

By using this site, you agree to our Terms of Use.