Bug: Read Key(Variant)__ogtk.vi [Variant Configuration File] looses variant name

[Bab]

Hi I signaled this issue about 2 years ago:

http://forums.openg....?showtopic=1088

Basically, for some data types, the variant name from the input is propagated from the variant input, and for some other data types it is not propagated.

The use of the LV node "To Variant" creates a variant with a standard name (the name of the input wire, ie no name or sometimes "value").

example: Integers I8..I32

The same is true for [u8..U32], [sGL..EXT], [CSG..CXT], [boolean], [string, DAQ], [Path]

The other data types: [Enum U8..Enum U32], [sGL PQ..EXT PQ], [CSG PQ..CXT PQ], [Array] and [Cluster] seem to propagate the variant name. I have not tested the vis, but by looking at the code it looks like it.

example:

I see 2 possible fixes:

1: using the OG SetDataName function:

2: using the NI FlattenedStringToVariant primitive and the TD of the input variant. This is the same that is used fo the PQ data types ([sGL PQ..EXT PQ] and [CSG PQ..CXT PQ]).

Solution 2 might be faster because the proper variant is created in one operation. In solution 1, the variant is first created and then modified. Anyone has an opinion on this?

How can this fix be integrated in a future release of the package? Can I help?

And by the way thanks again for these great tools!

BaB

-------------------------------------------------------------------------------------------

(I wanted to write the following as separate post but using reply just merges the reply with the original post... strange....)

As a side effect of the fix above, the Cluster case could be modified:

When the vi propagates the data names for all data types, there is no need to explicitly set the name again after the recursive call.

A second note is that the Cluster Name can be set directly with the optional input to the "Array of VData to Cluster" function, and the last SetDataName function to the right could be removed too.

Edited October 18, 2011 by Bab

[jgcode]

Hi Bab

Thanks for (re)posting.

I am actually in the process of trying to organize a large review on the OpenG Variant Configuration Library in the near future because there are a few outstanding issues and new features that it would great to integrate - stay tuned for this!

How can this fix be integrated in a future release of the package? Can I help?

Sure! There are a few ways you can help:

• Detailed reports (like you have done)
  
• Posting your code (in LabVIEW 2009)
  
• Becoming an OpenG Developer (if interested please PM me)
  

Each involves different degrees of time commitment, but it is totally up to you

Cheers

-JG

[Bab]

Thanks for the reply, somehow I missed it. I thought I should get an email since I am following this topic - is there something extra to activate?

JG: did you create a bug id in the bug tracking system? It would help ensure the issue is not forgotten again.

[Wire Warrior]

I will check tonight that this has a bug ID against it. If not I will create one.

Thanks

Jason

[Wire Warrior]

Hi bab,

Let's see if I understand the issue correctly.

As I understand it, when you use the Read Key(Variant)__ogtk.vi the name of the input typing cluster does not propagate. By this I mean the name of the cluster control/constant that envelopes the sub-keys. It is not the names of the sub-keys themselves you are talking about but of the collective entity.

Just wanting to make sure I trap the stated issue with my test.

Thanks

Jason

[Bab]

Hi Jason,

somehow I never get any notification even though the thread is marks as being followed by me - I should ask in another thread...

To be honest I am not sure I understand your question. The input variant wire "type" contains the "names" of the elements embedded (number, string, cluster, etc...). It is used to read the proper keys - and this works perfectly now. The problem is that the output variant (labeled "key-value") is not of the same type as the input variant: the names are missing or wrong.

I am posting the screen-shots from the original post from openg.org, since the picture are not displayed unless one is logged in openg. It does not point to the root cause but shows an example of undesired effect.

Here the Section Formatted Cluster contains a cluster with 2 elements: a string named "value" and a number with no name.

It is expected that the string would have the name "Name" and the number the name "Age".

When trying to get the "Age" element, nothing is found!

-> the workaround I have been using:

! This is not the final fix that I suggest. Fixing the root cause "Read Key(Variant)__ogtk.vi is the proper way (as discussed in the original post with Jim Kring)

The expected result look like this:

Now the elements of the VCluster have the right names and Getting the "Age" element out of the VCluster is working!

I hope I am not confusing you here.

I understand you are writing tests vis for Read Key(Variant)__ogtk.vi. Should I send a vi with my suggested fixes?

Can I see these tests, are they in the openg repository?

Cheers,

BaB