property node of a typedef disappears when typedef is changed

[Florian.Ludwig]

Hi community,

in a rather large vi I have a rather large cluster which is a typedef (see attached).

Whenever I change that typedef (e.g. add an element to the cluster) the sub vi pictured below (and attached) breaks.

It breaks because the property node of Rot 2 vanishes. Rot 1 and Rot 2 are of the same typedef.

(what the sub vi does: it compares two instances of the cluster for equal value except for a list of elements that need not be equal)

What am I doing wrong here? How can I avoid this behaviour?

Having to fix this (and one other) sub vi every time I edit the typedef kind of defeats the purpose of using a typedef for me.

Best regards

Florian

[LadyLabVIEW]

Hi Florian!

could you please attach the other cluster as well so i can try to reproduce the behaviour?

Could you also add a screenshot of the behaviour after you changed the typedef?

Do you always apply the changes before you save and close the typedef?

Regards!

[Florian.Ludwig]

Thank you milady for answering.

1. There is no other cluster. Both Clusters in the vi are of the same type.

2. The broken vi will look like this:

3. No, had not even noticed that "apply" was an option. Will do that from now on.

Funny thing: I had trouble provoking the behaviour just now although it always happens in the middle of a LabVIEW session.

Having just started the Session and not having opened a lot of projects or vis seems to prevent the problem to occur.

I do save all vis regularly during a session.

Regards.

[MangeshD]

Try using explicite property node for both the controls

[Florian.Ludwig]

Thanks for the suggestion.

I'll try one thing at a time. If always applying doesn't resolves the issue I'll try that next.

[Florian.Ludwig]

Update:

After 2 days it seems that applying before saving and closing solves the issue.

Will report back if I see that error again.

[Florian.Ludwig]

Update:

It happened again although I applied first.

Going to test LVKrAkEn's suggestion now.

[mikeporter]

I know this doesn't address the exact issue you are having, but you are sure going the long way around the bush to compare the contents of two clusters. In addition this technique could break in an executable due to the way optimization works.

How about this: use the equals comparator. The result is a cluster of booleans: one for each item in the cluster. Turn this cluster into an array and OR it with an array of the same size where elements that you don't care about are set to true. Now AND the resulting array. Done.

Mike...

[Florian.Ludwig]

Thanks for sharing that.

I didn't think of that - this vi is mainly copy&paste of a vi that compares two different clusters that contain largely the same elements.

For comparing instances of the smae cluster your way seems saver - and maybe faster. I think I'll switch over.

Now you've made me curious about the optimisation that could break this vi. Could you share your insight please?

Best regards

Florian

[mikeporter]

The problem is that if the VI's front panel is not open LabVIEW will optimize the actual controls out of existence, which means property nodes associated with those controls stop working - though curiously they don't generate errors.

They made that change back around 2009 or 2010 without so much as a footnote in a change file. And yes, it broke a bunch of code...

Mike...