Nugget - Using control references

[DFGray]

JoeLabVIEW, I was hoping this particular comment would show up, and you did a great job.

"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."

I personally believe that what customers want is not the first part of that comment, but the second two.  However, they think they need the first to get the second, which is incorrect.  I would much rather browse a hierarchical set of data with HDFView than scroll through an INI file with a text editor.  Both options are free.  Both have commercial, high performance versions.  Both are available on every platform LabVIEW is (well, maybe not the embedded ones).  But HDF5 and HDFView are much more suited to hierarchical data than an INI file.  I will be the first to admit that an HDF5 file is gross overkill for a simple configuration, but that is not what you were trying to do.

To reply to some earlier comments:

I like random access because it allows me to skip items I don't always need at this point / that are hidden, or that can be lazy loaded.

With floating point storage, you can always store more digits than you need, but you then bloat your file size and slow down parsing.  This is not a huge issue for configurations, since it is unlikely that a lot of floating point will be saved.  But I have been burned and seen others burned by not doing it right.  Using a binary file makes the issue go away.

Finally, having a hierarchical, binary config file allows me to stuff things into it that you just can't do easily with a text file.  The waveform example I gave above is one such item.  Images are another.  String tables are third possibility, although I tend to do that in a separate file.

However, you have to do something you are comfortable with and can support.  To each his own.

[Ray.R]

---

@DFGray wrote:

"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."

I personally believe that what customers want is not the first part of that comment, but the second two.  However, they think they need the first to get the second, which is incorrect.  I

---

How I wish non-software project managers would read your post!!!  😉 And thanks for the link on HDFView..   I (mostly) agree with you.  **My response below is not in dissagreement...**

... back to reality...

Actually, from experience, clients do want the traditional text format.  We both know that what they really want is the ability to view content and edit it.   When I explain other methods similar to HDF5, they do not feel comfortable.  The story I hear most often is that "someone tried somthing like that in the past and we could not support it after he left"..  Thus, the text-based on remains.   They are very reluctant from against using files that are not text.

Admittedly, I often get called in to "add features and debug" legacy code.  I have seen highly disorganized config files, many without headers.. completely ad-hoc.. 😞

Finally, this small nugget has brought a lot of discussion 😉    😄

It appears that there are topics for future nuggets:  Alternative methods to configuration files... 🙂

[shoneill]

"Actually, from experience, clients do want the traditional text format."

Yup, this is my experience too.  I guess the more non-programmers you have as customers, the more this is the case.  I believe the COmfort issue is an inportant one to understand here.  If a customer sees lots of padding or formatting he doesn't understand, it's a barrier.  Plain text is about as easy as it gets.

"Finally, this small nugget has brought a lot of discussion"

SMALL nugget?  Shouldn't we rename them to Mines, or Fort Knoxes?  They're getting a bit too big to be called nuggets any more.  I thought my last one was big, but Ben really trumped me on this one.....

Shane.

[Ben]

Shane wrote;

"

SMALL nugget?  Shouldn't we rename them to Mines, or Fort Knoxes?  They're getting a bit too big to be called nuggets any more.  I thought my last one was big, but Ben really trumped me on this one.....

"

I'm sorry Shane.

This Nuggets are evil beasts that spring to life and will not die until I post them and y'all help me bury them.

"Mines" yes, the mines of Moria and we are killing another troll.

Now were did I leave my mithril skivies?

Ben

[shoneill]

That would make Altenbach the servant of the secret fire I suppose!

Er, who am I?  Peregrin Took?

Shane.

[Ray.R]

Leave it to nuggets to bring out the Lords!!!!!

.... now where's my p-r-e-c-i-o-u-s.... ???

[JeanPierre]

Ben wrote:
"While the use of variants is acceptable, we must carefully observe that the format of the variant data is within the National Instruments domain and they can (and will) change its format or representation in future releases of the development platform."

While the internal representation and manipulation by LabVIEW of the variant data might (and did) change, its interface with the block diagram (mainly functions "Variant to Flattenned String" and "Flattenned String to Variant) have always been backward compatible with options such as 4.x and 7.x on relevant nodes. When NI did change Type Descriptors and Flattened Data formats, these options where available for compatibility. Remeber that data is written on file as flattened data and not supporting old formats would have make old files unreadable. There is little if any risk involved when using the power of variants.

Moreover, with LabVIEW 8.x, there have been major changes in TDs such that NI doesn't document them or make the new TDs available on the block diagram anymore. All functions using TDs will use TDs formatted to version 7.x. That makes variant manipulation tools like OpenG Data and Variant Config immune to further modifications in TDs at the high cost of never being able to support every newest and coolest data types. NI does provide the Variant Data Type library but it is still far from offering the broad functionality of the OpenG Tools.

About your ubernugget, Ben, what i have to say have already been pointed out.

• Data type: I would use GetTypeInfo.vi instead of checking errors on typecast
• Array sizes: Since you already use the flattened variant data (which is as "risky" as using a variant) why don't you extract the array size from that same  flattened data? That is the only straight way to do it. Read the number N of dimensions in the TD and the size of each dimension in the first 4*N bytes of the flattened data.
• Enums: You can use the Strings[] property to output the enum string itself. On Read an invalid string should trigger an error.
  

[Ben]

Thanks JPD,

That summarizes most of the issues I had with the example.

For sig figs I was thinking about using the formatting of the control itslef to carry the informantion.

As far as the file format goes, I have to second JLV's comments. I have customers who eyes light up when I tell them the config is in an ini. They are comfortable with ini's.

But extending the file writing part of this...

Mike Porter and I spoke off-line about how this technique can also act as front end to a DB (Is anyone shocked MP would like this idea ) ?

Ben

[tst]

---

@Ben wrote:

Mike Porter and I spoke off-line about how this technique can also act as front end to a DB (Is anyone shocked MP would like this idea ) ?

---

No, I'm not shocked.

I actually posted an example today (here) using the OpenG VIs to parse a cluster and build an insert query. I have another one which creates a select query, but I haven't used either of them.

As said there, I think the code was originally based on one of JP's examples, but I'm not sure.

[tst]

P.S. I did do a quick check on 8.5 and it seemed to work, but I wouldn't really expect it not to.