active review Variant Configuration Update

[jgcode]

This OpenG Review is active.

There are a few outstanding issues with the Variant Configuration as well as some feature requests so I thought it would be a good idea to start a summary thread to track them as well as to review all of these at the same time (in case of interactions etc...).

Note: What will be implemented and when is not the point of this thread - that will be decided at a later date by the OpenG Team.

If you know of an issue (link to an existing thread LAVA or OpenG), want to report something or have a new idea please post in this thread.

For anything new, please create (or I will create a) new thread so that it can be discussed in detail.

Please do not discuss these items in this thread - use that item's own thread.

• The point of this thread is to bookmark and manage these items for review
  
• I will keep this original post as up to date as possible
  
• An item with an ID link is a link to an OpenG Tracker
  
• Any item with a description link is a link to an existing thread (LAVA or OpenG)
  

I am pretty excited to see work done on this OpenG Library as this is my favourite OpenG API.

Kind Regards

Jonathon Green

OpenG Manager

Current Items for Review:

ID: 3411108 - Recursive OpenG VIs should use native recursion (if performance benefit)

ID: 3409853 - Reentrancy bug in Write Key (Variant) VI?

ID: 1501747 - Unnamed cluster elements cause problems

ID: 1156973 - Fixed size arrays & Read/Write Panel to INI

ID: 3004519 - Use custom decimal sign for floats

ID: 849694 - Units in INI-files?

ID: 848288 - Missing Key output

ID: 3004517 - Writing to Panel deprecated issues (LabVIEW 2009)

Bug: Read Key(Variant)__ogtk.vi: VI looses variant name

Throw error on duplicate data

Cannot load an array of classes using variantconfig

[Mads]

Regarding ID: 3004519 - Use custom decimal sign for floats, I hope the automatic solution is chosen. Otherwise you will have to know which decimal sign has been used up front and that is not the case when configuration files are shared between computers with different decimal signs (useful in client/server applications e.g.) I can write code that will open the file and check prior to calling the OpenG function of course, but that's not very smooth. Doing it automatically might not work perfectly for ever case (let's say that someone has specified the decimal sign to be something else than period or comma, after all you are free to do so under Windows at least), but then those users can analyze and specify the decimal sig. The automatics will still be able to offer a better solution for 95% of the cases...

[Wire Warrior]

So........What other thoughts does anyone have concerning the variant config library? Any thing?

Jason

[Wire Warrior]

Well since Mads was interested enough to post we will start with the ID:3004519 issue.

Mads, I saw on the old OpenG forums that you had linked a VI with a solution to the issue you were using. Would you mind posting that here again? The old forums don't let guests, like me :-), view the files.

TonP, You had linked an image of your solution. Do you still have that? Could you link here if so?

Thanks

Jason

[jgcode]

Well since Mads was interested enough to post we will start with the ID:3004519 issue.

Mads, I saw on the old OpenG forums that you had linked a VI with a solution to the issue you were using. Would you mind posting that here again? The old forums don't let guests, like me :-), view the files.

TonP, You had linked an image of your solution. Do you still have that? Could you link here if so?

Thanks

Jason

I can help with that:

Read_Key__Variant___ogtk.vi

PS - just so you know those forums were locked so if you didn't have an account before that, you won't be able to log in.

[Mads]

Sorry Jason, I never seem to get notifications from LAVA when there is a reply...But now you have the solution anyway, it's the same as Jonathon has posted. As I mentioned on OpenG there might be better ways of doing it, but it does the job.

[Wire Warrior]

Okay here is a screenshot of the modification that Mads made to work around the problem of matching the decimal point indicator.

Looking at this the first concern I have is that this assumes that the first period or comma encountered is the decimal point. This means that 100,000.00 would be interpreted as one hundred instead of one hundred thousand. It seems like a method that examines the input string for the existence of both commas and periods then makes a decision based on quantity would be a work around for that issue.

Of course this approach does limit the user to only two choices. I suppose we could include an optional input to the Read Key VI that would allow the user to assign any string as the decimal point indicator. I would propose that such a solution choose the first character of the string as the indicator. There is also the implicit requirement that the string be printable if humans want to read the character in a text editor.

What do people think about the cases where someone would want to use something other than a period or comma? I can't think of any localization types beyond those two but I will admit my experience is limited.

Your thoughts folks?

Jason

Edited February 14, 2012 by WireWarrior

[asbo]

It seems like a method that examines the input string for the existence of both commas and periods then makes a decision based on quantity would be a work around for that issue.

Why not just search the string from right-to-left? Throw in a string reverse and all should be well.

I've never seen localization options beyond period or comma, nor do I have an opinion on supporting other decimal characters.

[kombela]

Hi all!

I found an error, that the "Get Data Name from TD__ogtk.vi" doesn't handle the FXP numeric data type.

It is because the "Type Descriptor Enumeration__ogtk.ctl" Typedef doesn't have it listed. It would be the "0x5F" value.

Please have a look atit, it causes serions problems, when I try to run the "Write INI Cluster__ogtk.vi"

[Wire Warrior]

Thanks for the note Kombela. I will have a look at the VI this evening.

[Rolf Kalbermatter]

Of course this approach does limit the user to only two choices. I suppose we could include an optional input to the Read Key VI that would allow the user to assign any string as the decimal point indicator. I would propose that such a solution choose the first character of the string as the indicator. There is also the implicit requirement that the string be printable if humans want to read the character in a text editor.

The problem with this is that you start to accumulate a lot of (optional) formatting hinting parameters to the function quickly. Time format, floating point and decimal format, and what else. I wonder if a single string could work, where you use a syntax like the Format into String syntax to actually list all possible formatting options. Decimal point would be always the first formatting option like %.; and other formats could be looked for based on patterns such as %<.+>T etc,

[Phillip Brooks]

The TestStand API includes something called "DecimalPointLocalizationOptions"

http://zone.ni.com/r...izationoptions/

Rather than trying to guess what the decimal point is, maybe the Variant Config library could add a [OpenG_Locale] section within the INI file that would store the locale specific data at the time the INI was written.

Presumably the Variant Config INI file will be read using the library functions.

The saved settings in the INI file could be compared to the runtime locale settings (%c) and the library could convert if necessary.

The default-defaults could be used if the section was missing (non-OpenG INI or upgrading to new version of lib).

[Phillip Brooks]

I just contributed to a post on the dark side where I discovered that the fractional seconds component <%<digits>u> of the scan from string uses the regional settings to evaluate the input string.

My signature's "%^<%Y-%m-%dT%H:%M:%S%3uZ>T" is ISO 8601 compliant for CREATING a string because the spec allows for either separator to be used, but LabVIEW will always use the locale settings to PARSE the string.

In order to properly interpret an OpenG configuration file for this case, I don't see how it can be done without adding a section to the INI to store the regional settings for the last write to the file using the OpenG functions.

[Ton Plomp]

It's kinda sad to see that this LabVIEW bug isn't resolved after 4 years (and 8 updates),.

Ton

[asbo]

I would assume so by now, but do you know if it's actually been reported?

[Darin]

There may be hope:

http://forums.ni.com/t5/LabVIEW/Can-t-change-decimal-sign-in-timestamp-BUG/m-p/1865381#M632913

[Wire Warrior]

I just contributed to a post on the dark side where I discovered that the fractional seconds component <%<digits>u> of the scan from string uses the regional settings to evaluate the input string.

My signature's "%^<%Y-%m-%dT%H:%M:%S%3uZ>T" is ISO 8601 compliant for CREATING a string because the spec allows for either separator to be used, but LabVIEW will always use the locale settings to PARSE the string.

In order to properly interpret an OpenG configuration file for this case, I don't see how it can be done without adding a section to the INI to store the regional settings for the last write to the file using the OpenG functions.

Phillip's post makes me think that what we are discussing here are two options. One read the file with the computers localization information and the other read my file with the localization it was saved with previously. Determining the localization for the computer loading the file is easy. Determining the state of the file previously requires, as Phillip rightly pointed out, a field in the INI to report the information from the last save.

Of course, that still would not allow for us to support the work of a user with a text editor easily.

[d_laub]

I just posted this topic: 16552-variant-config-format-timestamps-in-human-readable-form, and wanted to record it here.  Saving timestamps to a human-readable format would be useful.