Dynamically referencing array elements

[shoneill]

Another work-around kludge is to programatically set the array to only display a single element, set index, write, and then re-set the array to the correct size and index.

As I said, a kludge, but it works independent of key-focus.

Shane.

[malosh]

Hi guys, I see I missed some action...

Been talking to Irit from the NI support also about this issue. Just now she got back to me with some news:

Apparently this is a known issue and it is about to be fixed in the coming version (8.0), if I will remember to pest them on time...

I was amazed to find out that viewing a single element solves this problem! This is not ideal for me, but I AM able to limit my GUIs to viewing single elements without creating a fuss. After all, as soon as I'll get a complete solution for this problem I will only need to recompile these GUIs without affecting anything else in the system!!!

Another thing I can do is save the settings of the 'Number of Columns', 'Number of Rows' properties, force these properties to '1' before activating the above 'Refnum to Array element' VI, and lastly - retrieve the original settings. I tested it already in the development environment, and it seems to be working great! I just don't know yet whether I can do such actions on an executable - but I will soon find out.

Thanks a lot guys for all the effort and great ideas - for me you already saved the day!

[TobiasHabermann]

I have a similar problem. I want to have access to values of controls placed in a cluster in an array. With clusters referencing works fine but arrays behave very strange so i do
it just like suggested before: i read the whole array and then just replace the element im interested in. But i dont know yet how to make this vi polymorphic. The arrayelement type (=type of the cluster) has to be passed anyhow. Im new to labview and still a little confused about this variant stuff and even not sure if this can be solved with variant types.

[malosh]

Take a look at how I do it.

No need for any 'polymorphic behaviour', this VI is robust, and can handle any array dimension and any element type.

There is only one thing you need to watch out from: as the 'Index Values' property changes, your referenced element changes (indexes to other element)!

So you have to keep the array control disabled, and the mentioned property unchanged for as long as you are using the reference.

There is also a "sizing" problem - there is no 'Array Size' property, and I didn't find a way to get such data from an array's reference without knowing the dimensions and element structure in advance...

[TobiasHabermann]

Thx a lot.
With polymorphic behaviour i meant : this vi should get passed only the array reference and any kind of cluster may be placed in the array (this works with this vi) and any kind of controls may be placed in that cluster, and then of corse any kind of "new value" has to be passed. And i dont know how to manage this without having acces to the cluster element types (maybe as strict type def). I have done it now by using 2 inputs called "string new value" and "numeric new value". Then i take one of this and convert it to variant. But i dont like this way because check for an empty string to decide which input to use which makes it impossible to set an empty string as  new value.
I would like to have this vi with only one input for any types of new values. Is this possible ?

[malosh]

The simplest way to do it is by pulling the varaint node to the interface. Now you can wire to this VI any kind of data.

Please let me know whether this hepls you, as I didn't understand what was your problem with the variant data.

Malosh

[tst]

You might want to have a look at the OpenG data tools written by JPD. They allow analyzing variant data, based on the Type Descriptor, which you can get as a property, and the polymorphism has already been written. Note that there are supposed to be some changes to the typedef structure in LV8, so these may not work until OpenG issue a new version.

[Dynamik]

Hi Tobias, Malosh,

      Attached is a modified version of Toibais' VI ("ar.vi").  The main addition is the LabVIEW type parser "ar1.vi" and LV-type-enum "ar1.ctl (care of OpenG.)  The type parser could be used as part of a routine to decompose a cluster - in a breadth-first search of the type commonly used to mine directory contents - in fact, I believe tst has posted this!  Interestingly, the Variant "type string" looks just like the normal LV type string - so the variant can be "parsed" as if it were a simple LVType!

I hope they don't change the type strings too much with LV8 - use at your own risk, I guess.

cheers

Message Edited by Dynamik on 10-06-2005 02:36 AM

Message Edited by Dynamik on 10-06-2005 02:37 AM

Message Edited by Dynamik on 10-06-2005 02:38 AM

[dwisti]

Sorry to bring up and old thread. I just ran into this issue/bug and it has not been fixed in 8.2. It was found by someone new to Labview in our group. While I understand this is bad design practice to reference an element in an array, why does the Labview expose the ArrElem.Value property?  Is it there to just confuse and already bad practice? Or should NI fix the IndexVals property?  Maybe a better description of the ArrElem.Value behavior is in order.

[Efosa O.]

dwisti hello.

Sorry to hear you have encountered this problem and that it has not been fixed. Would you mind posting a simple VI that exhibits the behavior you are seeing. Once we get it, we will take a look and try and replicate it.

Sorry once again and hope to hear from you soon.

EfosaO.
NIAE