Jump to content

Some data randomly loose its name when coerced to variant


Recommended Posts

As seen in the attached example, sometimes (unfortunately quite often) the coercion to variant is no longer working properly. The nameless type always coerce well, but the named type (data has name) do not. The data name is lost most of the time or, as seen below, another data name instance is substituted ... If you play with the attached VI, you will see the name changing from empty to correct to incorrect under no specific circumstances that I can reproduce (although in this case the fact the it use the other typedef instance name seam to give some indication of the direction to dig for NI people).

post-121-1169710614.png?width=400

Download File:post-121-1169710597.llb

This bug has been present since LabVIEW 8.0. The only work around that I know of is basicaly to never coerce to variant but instead use "To Variant" primitive (

post-121-1169710720.png?width=400

) on all the wire that will be passed to a variant input.

PJM

Link to post
Share on other sites

Good one you caught,

I was trying to start with OpenG Package builder, and somehow couldn't add VI's to my package....

Then I noticed saving and opening of a .ogbd file wasn't consistent the 'Package Files' tab was always empty. I found out that the [Files] section had no entries, debugging let me to this bug...

somehow the read-key doesn't suffer from this problem (maybe because there is only one item under [Files].

I also noticed that the Package builder uses a quit old version of the variant config VI's (2.4 instead of 2.7)

PJM, have you tested if this happens on all datatypes?

If packagebuilder needs to be updated that's quite some work.

Probably builder also needs updates..... Or builder should be elimated in 8+

EDIT:

In Package builder I have preceded every Write Key (Variant) and Read Key (Variant with the to variant primitive, now the package builder works. I tried to look up every to variant coercion dot with VI Analyzer but the number was a little bit to overwhelming... :(

Ton

Link to post
Share on other sites

Ton

...

PJM, have you tested if this happens on all datatypes?

...

I think that it does happen for all data type. I certainly have seen it happening a LOT since LV 8.0, but it is possible that this might be happening only for typedef or strict type def...

...

I was trying to start with OpenG Package builder, and somehow couldn't add VI's to my package....

...

EDIT:

In Package builder I have preceded every Write Key (Variant) and Read Key (Variant with the to variant primitive, now the package builder works.

...

Ton

Cool! I knew that the Package Builder was having issue above 8.0, but I never spend the time to investigate what was the issue. Now that we know what the bug is this should be easy to fix. Good catch.

PJM

Link to post
Share on other sites

PJM,

do you know if it is possible to do a search and replace with a merge VI? would be fun if we could replace the read (and write) variant.config vi's replace with a merged one including the to variant primitive

Ton

Link to post
Share on other sites

The bug looks like a side effect of the speed optimization for Variants that went into LV8.0. "If types are same, just preserve data." I think that only the types were compared, not the name of the type. I had no idea that was important to anyone, and so it doesn't surprise me that whoever wrote the code in the Variants was the same way. Data type name is something that we tend to play pretty fast and loose with within the LV code -- up to now, in my mind, it's pretty much there so that "Create Control" gets a decent label. Didn't know it was useful for something.

Someone should file the bug... I'm focused on other things today.

Link to post
Share on other sites

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.