issue (bug?) loading a class with DAQ device in private data

[GregFreeman]

See attached VI. Place a probe on the wire coming out of the Unflatten from XML. When the file is reloaded, the device is empty in the private data. If you look in the XML file, it's there. Is this expected behavior? I'm using LV 2012, I haven't confirmed on other versions.

issues.zip

Edited March 18, 2013 by for(imstuck)

[GregFreeman]

Let me know if anyone can reproduce (or not reproduce). The interesting thing is there is a config dialog example I downloaded a while ago that saves configs that have DAQmx device references like this and it works fine. I'm not going to attribute it to user error yet, but it was a long day so maybe I'm missing something obvious here.

[mje]

Confirmed. I remember in the past with things like this I've serialized them as strings. In fact I believe a DAQmx Name inherits from the native string type because you can wire up a DAQmx Name to anything that uses strings and vice versa.

 

I believe the logic is Names are system specific so are treated somewhat like refnums? Though it doesn't make much sense why they'd serialize the name to XML but not deserialize it. Who knows.

 

Anyways chances are your real use-case involves a class which hangs onto other state data which also might not need to be serializled, stuff like refnums, cached data, etc. When depending on native LabVIEW serialization-- which is very rare for me-- I often define a private data type/class which I create to hold only the information that needs to be serialized then throw that construct at the LabVIEW primitives. In your case I'd swap out the Name with a string.

[GregFreeman]

In your case I'd swap out the Name with a string.

 

That's what I've done for now (well, combobox). Thanks!

[JamesMc86]

Hey,

 

I replicated the issue and I think it is a bug as it works fine using flatten/unflatten directly or in a cluster. I filed a CAR with R&D under ID 398196

 

Cheers,

James