Passing Control Reference in SubVIs & Type Def

[pete_dunham]

This is a new topic but spawns from my earlier post : http://forums.lavag.org/Variant-To-Data-Wh...ter-t13974.html

I made a faulty assumption in developing code with relation to Type Defs and Control Refs. Thought I would post to see if anyone has run into the same issue or has a workaround...or a better approach

I have some sample simple code for explanation....

1)Below is the basic idea. The key components here are the Boolean Cluster (Cluster) which is a Type Definition (for example only, as right now I could use a boolean array for same functionality). And the Reference of this cluster; the reference is passed into code which can perform any action (see example). The type def can be modified (controls added and deleted) and this code will still work!

2)The same code as 1) but as a SubVI. This initially works...UNTIL I update the TypeDef. This results in a broken arrow

3) A created work-around. Which lets me have a subVI, but need to get array of Control Refs before. Can update Type Def and code will still run

So I infer from this code that the control reference is a static reference that is not dynamically linked to the control? Is this correct?

This seems like a limitation from passing type def. control references through subVIs...as the Control Ref is not dynamically updated (the subVI sink is looking for a different source if type def updated).

[jdunham]

Hey Cousin Pete:

QUOTE (pete_dunham @ May 6 2009, 09:44 PM)

1)Below is the basic idea. The key components here are the Boolean Cluster (Cluster) which is a Type Definition (for example only, as right now I could use a boolean array for same functionality). And the Reference of this cluster; the reference is passed into code which can perform any action (see example). The type def can be modified (controls added and deleted) and this code will still work!

First of all, you should generally use the conversion functions shown in place of a typecast.

QUOTE (pete_dunham)

2)The same code as 1) but as a SubVI. This initially works...UNTIL I update the TypeDef. This results in a broken arrow

...

So I infer from this code that the control reference is a static reference that is not dynamically linked to the control? Is this correct?

This seems like a limitation from passing type def. control references through subVIs...as the Control Ref is not dynamically updated (the subVI sink is looking for a different source if type def updated).

What you want to do is change the subvi control reference input to a more generic class:

Then you can pass any data type in there, and just check at runtime to see whether it contains any booleans.

[candidus]

As jdunham said, you should not use a typecast but the primitive "To More Specific Class".

As I remember it isn't a good idea to use a typecast on an array, better use a For loop

and cast the elements one by one.

Try the following (error handling omitted):

QUOTE (pete_dunham @ May 7 2009, 06:44 AM)

So I infer from this code that the control reference is a static reference that is not dynamically linked to the control? Is this correct?

This seems like a limitation from passing type def. control references through subVIs...as the Control Ref is not dynamically updated (the subVI sink is looking for a different source if type def updated).

I looked a bit further into this: It seems that the problem isn't the reference (it gets updated) but the SubVI's control terminal for it.

If you create the SubVI its reference isn't linked to your cluster typedef by default so it doesn't get updated.

You have to link it to your strict typedef by yourself.

[LAVA 1.0 Content]

QUOTE (candidus @ May 7 2009, 09:57 AM)

You have to link it to your strict typedef by yourself.

QuickTip:

You can link a control reference to a typedef by dragging and dropping the typedef-control onto the control.

Ton

[Aristos Queue]

RED ALERT. This is a LV crash waiting to happen. This is a very very very dangrerous piece of code: QUOTE

Let me explain what you have done: You have taken a control reference of one control and used the Type Cast to unconditionally change the type of the wire without changing the value of the wire. You are now calling operations on a cluster refnum that are only defined for a boolean refnum. The Value property itself may work at the moment, but you are one change in LV's source code away from crashing entirely if someone in R&D writes any code that assumes "if the type is this then I can do this" where "this" is an operation not defined for clusters.

I don't care how cool you think this is. It is fundamentally unsafe code. Normally if LV crashes that means there's a bug that LV R&D should be fixing. Hard casting refnums is one of only two ways that I know of that users can write code that can crash LV itself that is not a bug (the other being calls into a badly written DLL). You *can* get lucky on individual functions and not crash, but even then you cannot be sure that you are getting back meaningful results. Unfortunately, sometimes it doesn't crash and sometimes the results are meaningful, which can only encourage you to do this sort of thing more.

If you want to cast refnums, you should use the To More Specific and To More Generic primitives. If those prims give you broken wires for a given cast then that is a cast YOU ARE NOT MEANT TO BE ABLE TO DO. The Type Cast allows this hard unrestricted casting because there are cases where you are only using the refnums as lookup table numbers or something like that. It is not meant for changing types and then actually invoking methods.