LabVIEW

cancel
Showing results for 
Search instead for 
Did you mean: 

VI template and typedef change

Hello,
      When using the  "Call By Reference node", is it possible for changes to the callees' connector-typedefs to propagate to the "type specifier" automatically?  Right now I'm manually changing the "type specifier" when the callee's connector-pane changes - but sometimes I forget to. Smiley Wink
 
Thanks, Cheers!
When they give imbeciles handicap-parking, I won't have so far to walk!
0 Kudos
Message 1 of 7
(3,768 Views)

To [try to] put the question more clearly:

When calling "Open VI Reference" for use in the "Call By Reference node" a VI type-specifier called "type specifier VI Refnum (for type only)" is a required input.  I right-click on it and browse for the VI being called.  When the callee changes, it seems to require manually updating the VI prototype by [again] right-clicking on the type-specifier control and browsing for the VI.  Is there a way to "automatically" get the type-specifier to follow changes to the callee?  I tried pointing the type-specifier to a VIT, but changes to the VIT did not propagate to the Call By Reference node...

Am I missing something?

Thanks, cheers     

When they give imbeciles handicap-parking, I won't have so far to walk!
0 Kudos
Message 2 of 7
(3,747 Views)
Dynamik,

There is now way that I know of that will allow you to automatically update that type-specifier automatically.  However, you shouldn't need to update that type-specifier unless you change the connector pane.  Just to check that I made a couple of VIs with the same connector pane and was able to call both using the Call by Reference Node without changing the type-specifier.  I then went and changed the VI that I had created the type-specifier from and it still functioned as I would expect.  If you wanted to still call by reference you could just use a general VI type and use Invoke Nodes to set controls, run the VI, and get control values.  This obviously isn't as neat as the Call by Reference Node though.

Does this help?  Let me know if not!
Andy F.
-----------------------------------------------------------------
National Instruments
0 Kudos
Message 3 of 7
(3,735 Views)

Andy,

      I appreciate your looking at this, but my results don't agree with yours. Smiley Sad

> However, you shouldn't need to update that type-specifier unless you change the connector pane.

Attached are three VIs a caller, a callee, and a typedef appearing on the connector-pane of the callee.

Changing the typedef breaks the caller until the VI "type-specifier" is updated (manually.)

When using a "plug-in" architecture, the caller may load an old type-def that agrees with the [old] type-specifier - so the caller is happy.  However, the callee may use a new/different type-def, yet the problem won't show-up until it's called - under LabVIEW RUN-TIME, where there's poor "visibility" into the problem.  I don't see a way to improve this situation - but I'm open to ideas! Smiley Wink

Thanks, Cheers.

Message Edited by Dynamik on 05-12-2006 12:09 PM

When they give imbeciles handicap-parking, I won't have so far to walk!
Download All
0 Kudos
Message 4 of 7
(3,725 Views)
Dynamik,

I see what you mean.  I think what is happening is that while the actual depiction of the connector pane is the same, the information that it is communicating has now changed, so LabVIEW treats this as a whole new connetor pane.  All philosophical waxing aside if you wanted to do something similar you could pass variants or flattened strings.  If the input to the Callee VI was a Variant and the typedef controled what LabVIEW should convert the variant to, you could change the typedef all day long and not have any problems.  Would this be an acceptable workaround?

Repost if you have questions!
Andy F.
-----------------------------------------------------------------
National Instruments
Message 5 of 7
(3,710 Views)

Hi Andy,

      That's a very creative idea - it would eliminate the typdef-change problem - perhaps at the expense of conversion overhead (not to mention the philosophical/aesthetic implications.) Smiley Very Happy

It's very tempting....

I hope in future releases, NI will track the presence of a typedef in the type-specifier so that it can be updated as are other instances!

Cheers. 

When they give imbeciles handicap-parking, I won't have so far to walk!
Message 6 of 7
(3,705 Views)
Dynamik,

I would suggest submitting a product suggestion about this issue, so that R&D gets some feedback about what is causing difficulties.  I will do the same.

Thanks!
Andy F.
-----------------------------------------------------------------
National Instruments
0 Kudos
Message 7 of 7
(3,680 Views)