Add Format Specifier control in "Read Key (Double).vi"

[Priyadarsini]

The "Read Key (Double).vi" is not giving out proper values when a SI notation number is present in the ini file. For e.g. if the number is 1m it returns as 1 while the actual value should be 0.001. It will be helpful if the format specifier is provided as another control.

[AristosQueue (NI)]

> (why o why)... It's like everything possible is done to make this library non-reusable.

No. Everything was done to make this library *USABLE*. THIS library is the prime example of the need for access scoping. In 2010, we had the huge debacle when LV modified the private functions of that library and a wide swath of users complained that we broke their code. It was a nightmare... you can go read about it on the forums. I personally pushed for NI to make as much of that library private as possible. The public API is the parts that we support you using. Most of those VIs are not password protected. If you want to make your own copies and then modify them, go right ahead. But we aren't going to tie the hands of development to support inner functionality or force developers not to create subVIs just to avoid customers using them.

[wiebe@CARYA]

>No. Everything was done to make this library *USABLE*.

I think I just want more from a library that read's ini files. For example:

1) I often want to create an ini string from memory (no file).

2) I want to save without closing.

3) I want to save a copy.

4) I want users to be able to extend, and when I do a bugfix, benefit from it.

1, 2 and 3 are very hard without copying the library. I think my dislike for duplicate code is a good thing...

Private VI's make sense. I encourage them. As I see it, this lib should have a few "protected" middle level subVI's as well. Just to give a child class (wishful thinking) enough access to extend it.

[AristosQueue (NI)]

wiebe: I agree that it would be nice to have more functionality for this library. That wasn't what it was designed for. Its design predates LabVIEW classes. Your suggestions form a much broader idea request. 🙂

[wiebe@CARYA]

> Your suggestions form a much broader idea request. 🙂

Well, I've solved it by making my own library. It's super fancy (95% gold plating mixed with borderline feature creep ).

I could post an idea to include it in LabVIEW, but adding it to the tools network (first) is probably the way to go.

[drjdpowell]

>To get a recoverable string, you need to really push the width and the precision values up high, like this:...

It’s 17 digits you need to perfectly represent a DBL exactly in decimal.   To go the other way, and recover a decimal string from conversion to-from a DBL, one can’t have more than 15 digits (otherwise you get things like “0.6" becoming "0.59999999999999998”).  Unfortunately you can’t have both forms of perfect conversion, so you have to pick one or the other.  Personally, I think decimal formats (INI, JSON) should preserve the decimal representation, so if the User enters 0.6, it saves as 0.6.  Use binary formats for binary.

[wiebe@CARYA]

>It’s 17 digits you need to perfectly represent a DBL exactly in decimal.

No, you need a maximum of 17 digits. Some doubles (1, 2, 4, 8 for example) will be perfectly represented by a 1 digit string.

[PhillipBrooks]

---

@Priyadarsini wrote:

The "Read Key (Double).vi" is not giving out proper values when a SI notation number is present in the ini file. For e.g. if the number is 1m it returns as 1 while the actual value should be 0.001. It will be helpful if the format specifier is provided as another control.

---

A little late to the party, but the OpenG Variant Config library can handle this nicely

[wiebe@CARYA]

The quotes would be a deal breaker for me.. It's a number, not a string.

[PhillipBrooks]

INI is not a format.

It is a donkey with a sharp stick taped to its forehead.

The stick can be any length, and it's not always a donkey.