LabVIEW

cancel
Showing results for 
Search instead for 
Did you mean: 

Typedef Reference to Typedef Reference Control Wire Update Bug

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: 

 

ScreenHunter_002.jpg

 

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

Like this:

 

ScreenHunter_003.jpg

 

or like that:

 

ScreenHunter_005.jpg

 

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):

 

ScreenHunter_006.jpg

 

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.

 

0 Kudos
Message 1 of 4
(1,492 Views)

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

0 Kudos
Message 2 of 4
(1,422 Views)

@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.

Bill
CLD
(Mid-Level minion.)
My support system ensures that I don't look totally incompetent.
Proud to say that I've progressed beyond knowing just enough to be dangerous. I now know enough to know that I have no clue about anything at all.
Humble author of the CLAD Nugget.
0 Kudos
Message 3 of 4
(1,412 Views)

@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...

Message 4 of 4
(1,395 Views)