Re : How do I get the active or select row's columns from a tree ?

[Kochise]

Hello again,

I do face another problem with LabView (nooo, really?)

tl;dr : everything in the title

I'm  using a tree to display hierarchical data (neat dedicated

usage) but selecting an item, I can get the corresponding tag

and quite easily retrieve the corresponding text (column 0)

Yet, how do I get the corresponding column's elements in

a 1D string array ? I tried looping until to get an empty string

but not every cells are filled with data, so sometimes this

methodology fails. Is there a way to get the number of

columns, not just the number of (half) displayed columns ?

I tried looking for the interweb, the forum, lava, examples,

whatever, but found nothing explaining how just to easily

retrieve the columns from a given tag.

Have I missed something ?

David Koch

[Kochise]

The most closely related topic is this one :

http://forums.ni.com/t5/LabVIEW/Reading-all-of-the-the-tree-control-text/m-p/514182

Yet it doesn't answer my concern either.

David Koch

[Sam_Sharp]

There doesn't seem to be a method or property that allows you to do this so I believe cycling through the columns is the only way to retrieve the data from the tree control itself (perhaps something to suggest on the ideas exchange!).

Either that, or consider separating your data/model (clusters) from your view (the tree) and retrieve the information you need from the model instead of trying to retrieve it from the tree control directly.

[Kochise]

That's rather strange since when you feed 'Child text' with a

1D array of string, it is indeed stored somewhere.

Why retrieving this same 1D array of string is such a pain ?

So you can write data in the widget but not read it back ?

Why having to duplicate data storage all accross the application ?

No wonders why nowadays programs use so much memory...

I'd like to store and display data, not having to read it back

again and again from the data base. I just wanted to use the

tree as a data cache.

We're soon in 2015 and the issue is still open.

David Koch

[Sam_Sharp]

Yes - I agree with you that it does seem to be a method/property that's missing from the Tree Control in LabVIEW which is why I suggested posting it as an idea on the Ideas Exchange if it isn't already there. A method where you supply the tag and it returns a 1D array of the child text would be a sensible addition.

Memory these days is cheap...computers have gigabytes of RAM!

A lot of computer scientists will talk about Model View Controller (MVC) as an architecture...this is where your data (model - cluster?) is separated from the presentation of the data (view - in your case a tree control) and the controller ties them together with your logic of manipulating the data and updating the view.

One advantage of this is that using property nodes to read/write data from the tree control is slow compared to storing data in a cluster. If you're reading/writing from the tree control a lot you may run into performance problems further down the line.

In my applications I update the data in my cluster/shift-register more frequently but only update the tree control when I need to (e.g. every 250ms...the user doesn't need to see updates faster than that).

A simple workaround to this would be to implement your own method - wrap the Add Child method of the tree control and create a variant attribute lookup table that uses the Tree Tag as the key and the 1D array you write to the child text as the data. An FGV (Functional Global / Action Engine) could hold the variant and you can then retrieve the 1D array from the variant by the Tag name.

[Kochise]

I respect that idealistic view of MVC, yet, cluster and array of cluster

don't hierarchicaly sort itself, hence the use of a tree.

The problem of MVC is also not only duplicating the data in several

locations, it's also duplication of the accessors (provided a read

methodology is available)

Understand that feeding the tree with data is already pretty though,

so if you have to maintain a mirroring data model into clusters with

different hierarchy is not going to help much simplifying the whole

process.

It's a pain to have a somewhat easy data manipulation interface

using widgets, yet you still have to do the dirty data handling job

behind the front face. Then what's the added value beside the

cosmetic appereance ?

No wonders you finally gets 1000s of sub VIs because all the

expected basic funttionalities have to be coded by hand.

David Koch

[Sam_Sharp]

I think the main advantage is that let's say you decide you don't want to display your data in a tree control anymore and choose to use a table or a multicolumn listbox ...you would need to rewrite your entire code rather than just the code that updates the tree. It also means you can have multiple ways of displaying the same source data (e.g. different user interfaces for different users etc.) without having to obtain it in multiple places.

Anyway, it's a rather academic discussion but I wanted to mention it as it's one way to solve these sorts of problems and is very common in other languages (and yes...it's very front heavy as you have to create all of the getters/setters/methods etc.).

This very simple VI snippet should help you do what you want:

When writing to the tree, use this non-reentrant VI with the Set? = TRUE and then when you want to retrieve the data use the tag name and Set? = False to retrieve. You'll need to add error handling (and handling if the tag isn't found).