Nugget - Using control references

[Ray.R]

---

@Gabi1 wrote:

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

---

Hi Gabi1,

I stay away from relying on default values for front panel objects.  It is too simple to make unwanted values default.  There are a couple of approaches to avoid that.  One is using X-Controls, but you need the appropriate LV package for these.  The other is to read those values from a known source (usually static), such as an ini file.  Which is where this approach is useful.

---

@Ben wrote:

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.

---

Ben & tst,

I did the "testing" with LV8.2.  I did not observe any strange behaviour.

---

@tst wrote:

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

---

Now if this approach covered all angles, I'm sure Ben would release it as an OpenG tool.. 😉

.... maybe I shouldn't be giving him any ideas... 😄    Sometimes these "tricks" are needed to provide a more "robust (?)" - not exactly the word I was looking for... "predictable???)"

As I explained to Gabi1, you do not want to rely on default values to initialize front panel controls accessible to the Operator.  Plus, maybe you want to change their state..  An automatic "save as default" tool is dangerous... I see it in people's code when I am called to debug or implement features to existing code  -- sigh --   😞    Using X-Controls is not a solution for everyone..  So we need to consider something else..  such as using configuration file.  However, I have seen configuration files that are just completely crazy (can't post an example)..  The client spends 1/2 day just modifying config files to create new variants of test.  Now, with this tool, it is so much easier to do so..  You configure the controls for the test and this approach takes care of saving it for you.  Now on your front panel, if you save the settings by name, they can be later recalled "by name", thus providing you with the ability to try out various configuratuions and then even running them as a script (provide a list of "names" to recall is set order).  I see an application for an existing client that would need this approach.  Especially when the LV programmer spends more time editing config files than writing code... 🙂   The approach was actually legacy code left by someone else...

So..  maybe there are tricks...   But the real trick is how to deal with ever-changing configurations without getting your hands too dirty..  😉  ... or going insane...  ... or did Ben already pass that threashold 😄 LOL!!

Concerning the 3D array (post 6).. I can't imagine why someone would need that.  I'm trying to mentally picture it...  *** no... can't see it ***  🙂

---

@unclebump wrote:
I guess we know what Ben and JLV do in their spare time!!!

---

U.N.C.L.E.,

*** spare time!!???!!! ***     😉

[shoneill]

Tst,

Correct, picture didn't make it.  Those pesky Preview Buttons!

Here it is (maybe).



Shane.

Message Edited by shoneill on 08-27-2007 03:16 PM

[shoneill]

Tst,

  "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)" is correct and incorrect.  Indeed, this is where the sizes are coming from.  It seems I confused the two VIs when I posted the last picture.

Indeed this VI you are referring to is actually where the data manipulation I was referring to is taking place.



We see that the sizes are indeed being ripped from the flattened string data of the array.  Not only the TD.  I remain steadfast in my assertation that it's not possible to do this without "tricks".

Shane.

Message Edited by shoneill on 08-27-2007 03:25 PM

[tst]

---

@shoneill wrote:

We see that the sizes are indeed being ripped from the flattened string data of the array.  Not only the TD. 

---

Oh dear, that's twice you've got me in one thread. For some reason I didn't actually look at what was happening inside the case.

Can I attribute this to jet lag from NIWeek (I did return from S.F. which is a 10 hour difference)?

Yes, I can. It's jet lag from NIWeek.

[johnsold]

Thanks, Ben

I have just read through the thread, so I am probably speaking prematurely.

I like the idea of a method which can handle anything by searching the possibilities and looking for an error. Has it been checked with radio buttons or knobs with multiple needles and digital displays visible? I agree that speed is not a huge issue for something which only happens at startup or shutdown, but with 100+ controls it may become noticeable.

Extending the method to handle captions would be useful for language customization.

I have not gone back and searched the link, but I think I recall someone from NI posting that ClassIDs are fairly stable while ClassNames may be less so over version changes.

Lynn

[DFGray]

That's an impressive set of work!  I have a few comments to further fan the fires, so let me put on my flame-proof suit and proceed.

You can probably rely on the ClassID to remain constant (a lot of internal NI code will cease working if ClassIDs change).  This should allow you to create more efficient parsing mechanisms.  ClassNames can and have changed, so you cannot rely on them.

I don't like text-based configuration files for several reasons.

1. It takes awhile to parse them.
2. They are not random access
3. Precision of floating data types is almost always an issue
   
4. They do not handle large arrays very well
5. It is easy for the end user to change them
6. They don't have much hierarchy (unless you use XML, but that is whole level of complexity higher)
   

As a result, I usually use HDF5 (a hierarchical, binary file format) for my configuration files.  I then don't have to worry about binary type conversion and can put arbitrary hierarchy into the file.  In the above example, the data could be written directly to the file instead of being buffered to get the entire hierarchy before writing.  Large data sets can be compressed (yes, I have run into this use case).  HDF5 is self-describing, so I don't have to worry about losing type information.

Although I can see the utility of this sort of automatic state caching, I have never run into it as a use case.  I have always stored my internal state variables, not the state of a front panel.  This is probably just a comment on my coding style.

Once again, great work!

[tst]

---

@DFGray wrote:

Although I can see the utility of this sort of automatic state caching, I have never run into it as a use case.  I have always stored my internal state variables, not the state of a front panel.  This is probably just a comment on my coding style.

---

You should note that this saves and loads a typedef, not controls. It simply does it by using control references.

[shoneill]

Firstly, Ben, I'm truly sorry if I'm hijacking your thread.  I've said it once, and I'll say it again, great Nugget!

To answer DFgray, I think it's a lot to do with preferences.

1. True, it takes a while to parse (flexibility has its price somewhere!).
2. I don't quite get why random access is an issue, maybe I'm programming the wrong applications.
3. True, this is an issue but saving with one digit more than the type can hold should solve this problem (16 for DBL), no?
   
4. I cannot deny this.  I've played with the idea of putting binary blobs into the config file for anything over a 1D array, but it just gets fugly.
5. To me and a lot of the people I program for, this is a point FOR this approach, not against.....
6. They have a certain heirarchy in that the order of the cluster (or other control) gives the order in the file.  Not very elegant, but there is a certain heirarchy.

The elegance of this approach is that you can use it in "proof-of-principle" code to get up and running, and if performance becomes an issue, change it out for another method.  If performance doesn't become an issue, you've just written a portion of your code in a few seconds.......

I can't say I've any experience with HDF5, but I've been "hearing" a lot about it on the forum recently.  Anyone care for a HDF5 Nugget?

Shane.

PS Tst got there before me, the method is applicable to controls in general, not just typedefs.  The implementation may be limited to typedefs, but the method in general isn't.

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

[Ben]

Wow great thoughts all!

First, lets not overlook JLV's contribution. He had to read this Nugget a half dozen times and re-edit when I was doing one of those "What the he#@ is he talking about?" things.

Shane,

Hijack away! You carrying this Nugget virtually without my help.

tst and Dr Grey,

You are doing what I hoped.

So by my read we are down to two options for getting the array size. My hack and Shanes version.

Q1:

Wouldn't it be nice if there was an X-node that did the scripting required to accomplish this "trick" without resorting to control ref?

Idea:

If you thow out my file I/O stuff and shuffled things a little, code based on these concept could be used to repack a cluster of one order into a cluster with a different order.

Q2:

Has anyone tried this in LV 8.5 yet? (Ben covvers his head and hopes.)

BTW: I really do not like my "copy till it grows" method. I'm glad we agree on that point.

RE: the class of the control for parsing

The stability of the class ID has only recently come to light.

Keep them issues coming.

I love it!

Ben

[Ray.R]

Thanks Ben!  You did most of the work..  Cheers go to you!  😄

---

DFGray wrote:

I don't like text-based configuration files for several reasons.

...They don't have much hierarchy (unless you use XML, but that is whole level of complexity higher)...

As a result, I usually use HDF5 (a hierarchical, binary file format) for my configuration files.  I

---

Hi DFGray,

I agree with you...  Unfortunately, you were not involved in action before posting this Nugget...  All I can say is that I totally agree with you on the text-based configuration....  and that I was about to open a big can of worm with Ben on the subject of XML....  (I won't do that here either, but again... I agree with you).  We could have another Nugget to discuss xml as config file.  (Are you busy, Ben?) 😉

The "unfortunate" part is that in Ben & my case, we deal with requirements from our clients/customers.  Although I cannot speak for Ben, I'm sure he faces similar situations.  Most customers WANT a text-based configuration file.  They want it completely readable..  They want to look at it and they want to be able to edit it.  (where's they sigh icon...??? )

The test-based config file is in most cases "a customer requirement".  Either that or we have to deal with legacy code (I promisse I won't oopen a can of worms based on ... euh... existing customer legacy code)

I am like Shoneil, I have not yet used HDF5.  To my knowledge, the recommended (NI) approach to config files is XML.  However, I am willing to try other formats, including HDF5 as long as there is long-term support for it.  The challenge (in my case) is to "sell" the idea to clients who feel more comfortable with "proven" -cough- methods such as the good ol' text-based ini file...