From Friday, April 19th (11:00 PM CDT) through Saturday, April 20th (2:00 PM CDT), 2024, ni.com will undergo system upgrades that may result in temporary service interruption.

We appreciate your patience as we improve our online experience.

LabVIEW

cancel
Showing results for 
Search instead for 
Did you mean: 

Updating data in User Event doesn't propogate to uses of the User Event type

So I have a user event which is seeded with a cluster in which there are a few typedefs. Now, as you might expect, I have to pass the user event to different VIs so that they can trigger the events which are interpretted by a main vi. Pretty simple and all is happy. There's one rub though: one of my vis which is passed the user event is called by reference. The call by reference vi requires a certain vi pattern when you create the reference for the vi (namely, a strictly typed vi reference), which includes the user event type. Now, sometimes, I update the typedefs in the data type of the user event. This means that user event type changes. Now, what's maybe not too surprising, is that either the user event type doesn't update with the type def or that the type specifier vi constant doesn't update with the change in user event type. This means that every time I have to go back and create a type specifier based on the updated pattern for the vi which takes the user event as an input.

 

Is there a way for labview to automatically do this? One way to fix it, I'm sure, is to change the user event input into the vi I call by reference to a variant. Then inside the vi I call, to type cast the variant with the output of a Create User Event vi that has been seeded with the appropriate cluster of typdefs. But that seems pretty silly (like, why not just make EVERYTHING a variant). Any ideas?

 

- Chris

0 Kudos
Message 1 of 5
(2,306 Views)

Take a static VI reference (from the app control palette), drag your subVI into it, right click it and make it strict and wire it into the type input for the Open VI Reference primitive. Now it should always update.

 

Two more advantages you get from this is that now the VI is in memory, so it will automatically be included in your build and that you can use the VI Name (or VI Path) property from the static reference to get the name for the Open VI Reference primitive and it will always work correctly.


___________________
Try to take over the world!
Message 2 of 5
(2,294 Views)

Yeah, so close.

 

So I get the vi reference (and therefore it's type) from a subVi. The indicator on the output of this vi doesn't update! This is actually the principle issue I guess (which is covered by what I said earlier, but I wasn't as explicit and I shuld have been). For now I'll just make it a variant and cast it on the outside. Any help in doing it the 'right' way would be appreciated. Thanks!

 

- Chris

0 Kudos
Message 3 of 5
(2,266 Views)

I don't know if there's a way to automatically link a front panel VI reference to a specific VI, but at least if it breaks, you can right click and select the new pattern from the Select VI Server Class>>Strictly Typed VIs list. Personally, I think I would prefer that to a variant, as it's safer.


___________________
Try to take over the world!
0 Kudos
Message 4 of 5
(2,255 Views)

Yeah, I'm gonna stick with the variant. I lose compile time type checking, but gain less headaches as I often update the typedef. As long as I'm not a total idiot and don't change the vi I get the reference from, I shouldn't get any headaches from the Variant to Data at run time when it checks the type.

 

Thanks for your help.

0 Kudos
Message 5 of 5
(2,249 Views)