Jump to content

Variant Configuration Update


jgcode

Recommended Posts

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

Link to comment

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

Link to comment
  • 3 weeks later...
  • 2 months later...

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

Link to comment

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:

post-10325-0-43118300-1327984270_thumb.p

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.

Link to comment

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.

Link to comment
  • 2 weeks later...

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

post-9739-0-70417900-1329181935_thumb.pn

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 by WireWarrior
Link to comment
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.

  • Like 1
Link to comment

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"

Link to comment

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,

Link to comment

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.

post-949-0-21811900-1329831388.png

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 :wacko: could be used if the section was missing (non-OpenG INI or upgrading to new version of lib).

Link to comment

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.

Link to comment
  • 2 weeks later...

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.

Link to comment
  • 11 months later...

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

×
×
  • Create New...

Important Information

By using this site, you agree to our Terms of Use.