Unbundle By Name Changes Selected Field
Posted 11 June 2012 - 07:15 PM
Here's the code for a VI when it's opened on my main development machine. Note the unbundle by name primitive is selecting the ER field:
Now here's the same code opened up on my laptop:
Yeah, somehow the unbundle by name prim now selecting the DN field and the corresponding case structure has also mutated its type. Fixing this is dead simple, I just re-select the ER field, but the more important question is why is my source code changing as a function of which computer opens the VI? This scares me...
Posted 11 June 2012 - 08:48 PM
That might not be your problem, but it is a situation that would result in the weirdness you're seeing that I have actually had happen to me in the past.
Posted 12 June 2012 - 08:37 PM
Clearing the object cache or forcing a recompile had not showed any sign of working either. I also verified the issue on a pair of development virtual machines I run, both had the wrong field selected when opening thier copy of the same source code revision.
It seems the only instance where the correct field was selected was on my main development machine. After saving the VI on another machine, committing to SCC, and updating my main development version the problem seems to have vanished. Yay?
Posted 13 June 2012 - 12:52 PM
Posted 13 June 2012 - 01:30 PM
I have seen this before, but never in a situation I could recreate. It is a bit scary as luckily in your case the code got broken by the type of the unbundle output changing, but it could have changed to another cluster element with the same type.
Indeed, that's what I find scary. Had the type not changed it would have been one hell of a bug to hunt down.
Posted 13 June 2012 - 07:03 PM
This is mostly just conjecture, but it is along the lines of what I could imagine our implementation doing. Are all your VIs saved in a state that is consistent with all your typedefs?
Posted 14 June 2012 - 01:38 PM
That makes sense as I recall the history of the control pretty much followed what you assumed.
The most likely situation I can think of is that there are typedef updates happening during the load. The node knows it is looking for the name "ER". At some intermediate point in the load, the node sees a version of the cluster that has no field named "ER". It could decide to fall back to the index, which is now named "DN". After all the updates are complete, the cluster now has both the "ER" field and the "DN" field but it now thinks that "DN" is the right name so it stays there.
They should be. The typedef in question is actually the ctl that defines the private members of a class, so I imagine all of the member methods would have been in memory and saved along with the class by the save all operation, and I had not been playing around with the files outside of the LabVIEW context. This might be another instance of the history information carried around by LabVIEW classes causing unintended problems.
Are all your VIs saved in a state that is consistent with all your typedefs?
For what it's worth, the offending file is attached (without the containing class library). Not sure if you can pull any information out of it. When opened on my desktop computer, the UBN node picks the ER field, but any other system I have tested it on the UBN node picks the DN field. If relevant, I can get you (or anyone at NI) the whole class library if you contact me via PM, I've taken note of the SCC revision number where I captured the problem.
Edit: Scratch that, reverting to the revision I had noted no longer shows the problem. The VI seems to always select the DN field now...argh.
Posted 24 June 2012 - 09:41 AM
This is happening because of objects. There has been a discussion on the NI-site and Steven mentioned not to use typedefs in objects.
I hesitated to do this but when thinking along I accepted that typedefs are not necessary in objects. In fact the object itself is the typedefinition.
I now only use typedefs when interfacing to an object but not in the object definition itself and no problems anymore.
I beleive I had this problem in five different situations and getting it fixed took a lot of editing.
I don't say it is a bug and indeed should be solved but for now I can live with it because indeed a typedef is not necessary in an object.