Reordering of strict typedef cluster results in scrambled references in sub-vi's

[GLNuvera]

I am reordering the elements in a cluster (which is a strict typedef), however any vi that references this typedef gets its references scrambled.  To add to the problem, the sub-vi's wires don't even break.  The only solution seems to be a search of each of the typedefs elements in all of the vi's and checking if they are referenced correctly.

[JeanPierre]

That is why you should use bundle/unbundle by name on typedef clusters as much as possible. Doing so the code doesn't break when you modify/reorder the typedef.

[GLNuvera]

I actually do use unbundle by name in the sub-vi's.  The links break if elements are deleted from the strict typedef cluster, but if elements are added to the cluster the wires do not get broken and the unbundle by name just gets offset and points at the wrong element.  Much harder to detect if its unbroken...

I've tried different ways of editing this, but don't seem to get LabView to match up the names in the typedef cluster with the unbundle by name.  It seems that LabView is using a straight out enumeration of the elements with out checking the names of the elements for additions.  Is there a way around this?  With over 25 sub-vi's using this one typedef, it takes a while to make sure that everything is pointing to the right name...

[Ben]

This sounds like the BUG I hate the most!

It is the one that will incorrectly choose the first cluster element that is the right data type and completely ignores the names that was originally selected in both "Unbundle by name" and "Bundle by Name".

This BUG was present in LV 7.0 and 7.1 and has been reported as fixed in LV 8.0.

If my undestanding of this issue is incorrect, please post a small example to demonstrate the issue.

Ben

Note:

I hate this bug because it makes LV developers look stupid or lazy. The second time I got bit by that bug, the customer called me up after recieving an update and asked "Ben, did you even test this code? Why is my velocity showing up in my RPM indicator?"

[johnsold]

I have a strict typedef cluster to which I have added elements several times without seeing anything like what you describe. Is it possible that at some time the wires or unbundle nodes were created from a non-typedef version of the cluster? If so, they might be "related" to the "old" version and might cause the effects you are seeing.

Post a simple example showing the effect, if possible. Someone will likely be able to identify the problem and a solution.

Lynn

[Ben]

See this thread for more info on the bug I was talking about.

http://forums.ni.com/ni/board/message?board.id=170&message.id=108078&query.id=0#M108078

Ben

[GLNuvera]

Thanks Ben, that is the same issue and I am using LV7.1 and not LV8.  I somehow missed that previous thread.  I'll have to play around with the problem again (just trying to get it done right now), but I seem to have bypassed the issue by just editing the typedef cluster with no other vi in memory.  I then opened the top vi and everything linked up okay.

I'll try it in a smaller test case when I have some time and can report it to this thread, but am certain that I am dealing with the same issue.

[Ben]

"... but am certain that I am dealing with the same issue."

If you do not think it is a new bug, you do not have to post another example. I was asking for an example if you though it was a new bug.

Thanks for the intent!

Ben

BTW:

THe First time I was bit by this bug it was in an application with 500+ VI's and the symptom was "It uses more memory asw time goes on and re-booting does nto help!"

It turns out Darren's VI Analyzer found that I was doing a "Bundle by Name" twice at warned me about it. This resulted in the application attempting to load all events from the begining of time!