Typedef Reference to Typedef Reference Control Wire Update Bug

[X.]

A reference to a Typedef-ed control should know which Typedef it is associated with. I mentioned a slight lack of feature regarding this one year ago.

It is very likely that if you have created such a reference, you will use it to access your control's value in a subVI, like this: 

If you take a look at such a subVI, the reference control can look two different ways.

Like this:

or like that:

if you have chosen to "Show Control" rather than "Show Icon".

The control in the reference box above "knows" that it is associated with a Typedef, and you can access that Type Definition from the reference control in its second form above (but not in its first form, which is a variant of the problem I mentioned in the thread cited above).

Now, if you modify the definition of the Typedef itself, here is what happens on your diagram (after having used "Apply Change" on your Typedef):

The wire is broken, even though both objects know that they are associated with the same Typedef.

The magic "Ctrl-Run Arrow" will fix that, but there seems to be no reason why the wire connecting a reference to a typedef control and a similar control in a subVI should break.

I'd say this is a bug.

Note: This might be vaguely related to this older report of mine here.

[Karl-G]

This is likely due to how LabVIEW stores the compiled version of the VI in memory. When the Typedef is changed, it is not dynamically causing the top level VI to update the control reference. That is why the control/click on the run button works; it forces a recompile of the VI and its dependencies and loads the new Typedef into memory.

http://digital.ni.com/public.nsf/allkb/C1C6FE6231966E278625661F0054A970

[billko]

---

@Karl-G wrote:

This is likely due to how LabVIEW stores the compiled version of the VI in memory. When the Typedef is changed, it is not dynamically causing the top level VI to update the control reference. That is why the control/click on the run button works; it forces a recompile of the VI and its dependencies and loads the new Typedef into memory.

http://digital.ni.com/public.nsf/allkb/C1C6FE6231966E278625661F0054A970

---

Interesting.  I always updated the reference by dropping the new typedef into it.  Recompile seems much easier.

[X.]

---

@Karl-G wrote:

This is likely due to how LabVIEW stores the compiled version of the VI in memory. When the Typedef is changed, it is not dynamically causing the top level VI to update the control reference. That is why the control/click on the run button works; it forces a recompile of the VI and its dependencies and loads the new Typedef into memory.

http://digital.ni.com/public.nsf/allkb/C1C6FE6231966E278625661F0054A970

---

This is precisely why I use the magic combo, but my point is that, since I choose to "Apply Changes" after having modified my typedef, I'D EXPECT this to be reverbarated down the hierarchy of VIs referring to this typedef.

Now if you are telling me: "no way, why would "Apply Change" mean "Apply Change", that's a ridiculous assumption! And a broken arrow is no biggie! Just Ctrl-Run Arrow whenever you modify a typedef (on top of "Applying Change" of course!)" then I am a perfectly happy customer!

After all, who am I to expect things to behave as advertised?

PS: Now that I think about it, I must have reported that before, and there might be CAR for that already...