Nugget - Using control references

[tst]

---

@Gabi1 wrote:

btw, for those who still like to use : make current value defaults, thats how it might be done:

---

You should note that this method will not work in an executable , because the run-time engine cannot save VIs.

---

For enums, i generally never let the user update them directly, but always trough an external vi, that saves both the string and the value.

---

It's also important to note that the problem here is with the programmer changing the typedef enum. If the programmer is only adding elements at the end, then you have no problem. The problem is that you can't rely on the programmer doing that. You have to account for that somehow, either by throwing an error if the value was not found or by using a default value (probably throw an error because you wouldn't want the values changing behind your back).

It is true that users should not usually see enums on the front panel, but have a ring with some sort of translation from the ring values to the enum values.

[shoneill]

Tst,

OK, the re-usability part of Ben's version may be different.  It's certainly POSSIBLE to have a muchmore general version of it. Point taken.

Agreed, flexibility (epecially "tricky" ones like these), are rarely fast.

Regarding tricks stopping to work.  I'm pretty pragmatic on this one.  NI may or may not change a whole boat-load of things in future versions.  I'd rather not try to second-guess their future moves but rather concentrate my efforts on the best current method available.  I also don't think they're going to get rid of variants completely (or radically change them) without having something else with similar (or better) functionality available.  Heck, maybe NI will give us a function to exactly what Ben's describing here, thus negating the need for this discussion.....

I had a look at the tool in the GetType.llb, but I don't think this works.  LV stores the array sizes as -1 since LV has dynamic sized arrays.  The Type Descriptor therefore does NOT store the actual size of the array.  At least it didn't in LV 6.1.  I just checked, and this is true for 8.2.1 also.  It's NOT possible to get the array size this way (unless always getting -1 is of any use).  Wire up an array and check it out.  This why "tricks" are required to get the array size.

Shane.

Message Edited by shoneill on 08-27-2007 09:11 AM

Message Edited by shoneill on 08-27-2007 09:12 AM

[tst]

---

@shoneill wrote:

Regarding tricks stopping to work.  I'm pretty pragmatic on this one.  NI may or may not change a whole boat-load of things in future versions.  I'd rather not try to second-guess their future moves but rather concentrate my efforts on the best current method available.  I also don't think they're going to get rid of variants completely (or radically change them) without having something else with similar (or better) functionality available.  Heck, maybe NI will give us a function to exactly what Ben's describing here, thus negating the need for this discussion.....

---

I generally would agree, as long as the trick seems encapsulated and sound enough.

---

I had a look at the tool in the GetType.llb, but I don't think this works.  LV stores the array sizes as -1 since LV has dynamic sized arrays.  The Type Descriptor therefore does NOT store the actual size of the array.  At least it didn't in LV 6.1.  I just checked, and this is true for 8.2.1 also.  It's NOT possible to get the array size this way (unless always getting -1 is of any use).  Wire up an array and check it out.  This why "tricks" are required to get the array size.

---

I see you missed it again.
GetType.llb is what 7.x had.
8.x has a new folder with VIs which do return the dimension sizes.

In the OpenG code, the dimension sizes are extracted from the TD of the variant, not of the array itself.

[shoneill]

Don't meant o be a pain, but even the version in the 8.x installation folder doesn't return the actual size of the array.

Here's a pic of what I get when I run it...



Maybe your LV version / installation is different to mine?

Shane.

PS a further correction : The OPenG versions do not get the sizes from the TD, they use the TD and the flattened data of the entire array.  Only using the TD, this is not possible.

Message Edited by shoneill on 08-27-2007 11:58 AM

Message Edited by shoneill on 08-27-2007 12:04 PM

[shoneill]

Here's a version I once implemented to find the size of an array described only by an array object reference.

It relies on re-casting a Variant to a n-D Variant array.

Written in 6.1 (and still works).

Shane.

[Ben]

Thanks for all of the comments!

I can only address some of the issues at the moment.

Although I have been try to get this code running since LV 6.1 i only assembled all of the right "tricks" in LV 7.1 were i did most of my testing.

I'll look for the libraries you mentioned tst. They may be just the ticket.

If the example Shane posted is the same one I saw off-line, his method is perferable to my fat-fingered approach.

Thank you Shane!

Run in the UI thread?

Yep! The top level VI's are configured to run in the UI thread rather than forcing thread swaps for every other node.

Gabs,

You sound like you are running in the same track as me. Everytime I sat down to write a new "save-Restore" I was motivated to figure out how to do it once and forget about it.

I re-read the mreplies again and post back latter.

Have Fun!

Ben

[shoneill]

Ben,

You're welcome.  It's the very same method.  It DOES create a data copy, but I have yet to see a method for this which doesn't.....

It will break if the casting of a (array) variant to a Array of variants does not work any longer.... I believe some of the OpenG VIs use this functionality too.

It also has to be hard-coded to a limited set of n-D Arrays (Is this REALLY a problem? Can this be solved with some more "unofficial" NI features?)

Shane.

[tst]

---

@Ben wrote:

I'll look for the libraries you mentioned tst. They may be just the ticket.

---

Maybe, but I believe I was thinking of the VI in the image Shane posted. Either I didn't test it (quite possible) or I was thinking of another VI (unlikely) or it only started working in 8.5, but I can't check at the moment.

Shane, I only had a quick look, but it looks like the OpenG code takes advantage of the fact that the array data is saved flat and simply uses that with some dark magic TD manipulation to generate a 1D array of variants (see the attached).

[shoneill]

Tst,

correct, the "dark magic" is all explained in the document I linked to in a previous reply.  It then creates a flattened dimension array of 32-bit numbers, which is then re-cast to a proper array.

In the following image, the highlighted parts are the parts relying on the flattened data of the array.  This is NOT part of the TD.  This string being worked on contains ALL of the data in the array, not just the sizes.  Of course we can cut it as required and surgically remove the array sizes, but this is similar to the method I have just posted, just on a lower level.  Both operate on the DATA of the array, not just the TD.

Shane.

[tst]

In the last post I was only refering to the conversion of an array to a 1D array of variants. The actual dimension sizes are determined by analyzing the TD of the variant holding the array (the VI in the left side of the internal case structure). As you say, it requires duplicating the array itself by converting it to a variant.

BTW, your image wasn't attached.