handle controls via reference

[peterridder]

Dear Developers

If you handle cluster controls of a vi with references to them, Labview provides a variant Data if you comnect the reference (not strictly typed) to a property node and choose value as property.

With the VariantToData Vi and the structur information - a constant copy of the cluster - you get the data back.

How could I get the data back, if I only have the reference.

Have I to deal with the type discriptor?

My aim is to lay down all setup information in one cluster and give all involved vis only a reference to this control (but not a strictly typed one)

regards

Peter

[Dan DeFriese]

If the cluster is type-def'd you can do something like that below. In this case the cluster on the BD is just used for type input to the variant to cluster.

[Mark Smith]

First, I think you have to have some way to strictly identify the control you want to retrieve using the reference. Creating a typedef of the control and then using it exclusively to write and read the control cluster will keep your code in sync - if the typedef changes, all users (controls and VIs) will update automatically.

Then, I'll be the first here to say that this is probably a BAD IDEA! The most important reason is that this forces all of your code into the UI thread - here's a link to and quote from an NI page

http://zone.ni.com/r...xecution_speed/

Using Controls, Control References, and Property Nodes as Variables

Though you can use controls, control references, and Property Nodes to pass data between VIs, they were not designed for use as variables because they work through the user interface. Use local variables and the Value property, only when performing user interface actions or when stopping parallel loops.

User interface actions are historically slow on computers. LabVIEW passes a double value through a wire in nanoseconds, and draws a piece of text in hundreds of microseconds to milliseconds. For example, LabVIEW can pass a 100K array through a wire in 0 nanoseconds to a few microseconds. Drawing a graph of this 100K array takes tens of milliseconds. Because controls have a user interface attached, using controls to pass data has the side effect of redrawing controls, which adds memory expense and slows performance. If the controls are hidden, LabVIEW passes the data faster, but because the control can be displayed at anytime, LabVIEW still needs to update the control.

So, what's a good solution? One is to pass the cluster by wire (simple and fast). If you use typedefs, this is every bit as simple as wiring control refs together. If you need decouplig from the wire, use a single element queue (one VI puts the data on the queue, another takes it off) and used named queues. If you must pass refs by wire from VI to VI, then you could pass the queue ref and use the queue as the data container. If you want mutilple listeners, use a Notifier. And lastly, I think a Data Value Reference (new in LV 2009) would work well, although I'm not up to LV 2009 yet.

Mark

[Ton Plomp]

Using the OpenG Variant Tools, you can investigate the contents of any variant.

Using this data I have written a XControl that presents the data inside a variant on a tree.

Ton

[peterridder]

First, I think you have to have some way to strictly identify the control you want to retrieve using the reference. Creating a typedef of the control and then using it exclusively to write and read the control cluster will keep your code in sync - if the typedef changes, all users (controls and VIs) will update automatically.

Then, I'll be the first here to say that this is probably a BAD IDEA! The most important reason is that this forces all of your code into the UI thread - here's a link to and quote from an NI page

http://zone.ni.com/r...xecution_speed/

Using Controls, Control References, and Property Nodes as Variables

Though you can use controls, control references, and Property Nodes to pass data between VIs, they were not designed for use as variables because they work through the user interface. Use local variables and the Value property, only when performing user interface actions or when stopping parallel loops.

User interface actions are historically slow on computers. LabVIEW passes a double value through a wire in nanoseconds, and draws a piece of text in hundreds of microseconds to milliseconds. For example, LabVIEW can pass a 100K array through a wire in 0 nanoseconds to a few microseconds. Drawing a graph of this 100K array takes tens of milliseconds. Because controls have a user interface attached, using controls to pass data has the side effect of redrawing controls, which adds memory expense and slows performance. If the controls are hidden, LabVIEW passes the data faster, but because the control can be displayed at anytime, LabVIEW still needs to update the control.

So, what's a good solution? One is to pass the cluster by wire (simple and fast). If you use typedefs, this is every bit as simple as wiring control refs together. If you need decouplig from the wire, use a single element queue (one VI puts the data on the queue, another takes it off) and used named queues. If you must pass refs by wire from VI to VI, then you could pass the queue ref and use the queue as the data container. If you want mutilple listeners, use a Notifier. And lastly, I think a Data Value Reference (new in LV 2009) would work well, although I'm not up to LV 2009 yet.

Thank you for your suggestions.

I have allready severall parallel modules which are running in different execution systems and communicating with queues.

But from time to time measure rates etc. are changing and then i have to pass this new setup informations to several modules.

And I would like to have just one reference to one generel setup control, just to load the new informations before a new measure cycle starts.

So the question for me is.

How get I the data from some cluster control which is located on some tabcontrol in some SetUp.Vi

If I use the vi reference -> frontpanal ref ->controls[] ->tabcontrol -> etc. I will only get back variant data and I must provide additional structur information to use the VariantToData Vi. But if I do so, and I change some parts in the SetupCluster, I have to change the type Information in every single place. That's what I try to avoid.

regards

Peter

Mark

[Mark Smith]

So the question for me is.

How get I the data from some cluster control which is located on some tabcontrol in some SetUp.Vi

If I use the vi reference -> frontpanal ref ->controls[] ->tabcontrol -> etc. I will only get back variant data and I must provide additional structur information to use the VariantToData Vi. But if I do so, and I change some parts in the SetupCluster, I have to change the type Information in every single place. That's what I try to avoid.

regards

Peter

Dan's reply has the solution - just make the SetupCluster control a typedef and then use the typedef everywhere you want to write or read the data. If you change the typedef and then execute "Apply Changes", the typedef will update everywhere you use it so all of the places you use the typedef to unpack the variant will update automatically. No work required on your part.

Mark

[asbo]

But from time to time measure rates etc. are changing and then i have to pass this new setup informations to several modules.

And I would like to have just one reference to one generel setup control, just to load the new informations before a new measure cycle starts.

This really makes me think functional globals.

[peterridder]

Thank You, I will try this one.

[PaulL]

A few things:

1) Why not strict typedefs? If we use a typedef, we pretty much always make it a strict typedef!

2) If you can use a wire to pass the data (usually best within a software layer) you can use a strict typedef'd cluster or a LabVIEW object. This works very well.

3) If you can't use wires to pass the data (for instance, you want to separate the View from the Controller--highly recommended!), that is, you want to know what the current value of a control is at some other layer in the application, there are several approaches to resolve what is essentially now a communications issue. Hence there were the suggestions for queues, notifiers, and functional globals. One simple approach (and the one I would use) is to bind the control (strictly typedef'd, of course) to a shared variable and then read the shared variable on demand. Shared variables also have the advantage that they work across a network.