LabVIEW

cancel
Showing results for 
Search instead for 
Did you mean: 

Generate user events by name?

Solved!
Go to solution

You'd also have to distribute all user events to all event structures, while for previous solutions only the registration needs the specific user event . No problem if it's all contained in a class of course, but it might be restrictive.

 


Not true, the code makes a pre-selection (a sub-set of the events) for each consumer. Whether this is a single event or a sub-set depends on the specific requirements of the code. Int he example, there are 4 events, each consumer receives and registers for two. No single event is registered for by more than one subscriber.

0 Kudos
Message 11 of 14
(230 Views)

@Intaris wrote:

You'd also have to distribute all user events to all event structures, while for previous solutions only the registration needs the specific user event . No problem if it's all contained in a class of course, but it might be restrictive.

 


Not true, the code makes a pre-selection (a sub-set of the events) for each consumer. Whether this is a single event or a sub-set depends on the specific requirements of the code. Int he example, there are 4 events, each consumer receives and registers for two. No single event is registered for by more than one subscriber.


Fair enough.

 

You still have to somehow distribute the two arrays with enums filtered user events.

 

The wires will just transport less data.

0 Kudos
Message 12 of 14
(209 Views)

wiebe@CARYA wrote:


Fair enough.

 

You still have to somehow distribute the two arrays with enums filtered user events.

 

The wires will just transport less data.



Well, yes, obviously.

How else are the consumers supposed to receive their "link" to the producer?

 

Perhaps I just don't understand where the problem is exactly.

 

0 Kudos
Message 13 of 14
(205 Views)

BTW. a hacky way to get effectively the same functionality is to not use user events...

 

Make a VI with (Boolean) controls:

wiebeCARYA_3-1694699656040.png

 

Now you can get specific control refs by filtering on label and register to the value change events.

wiebeCARYA_1-1694699482371.png

Triggering an event is done with a value (signaling) property.

 

A (minor) benefit is this VI can be called anywhere, acting as a global reference source (I'd make the VI private so it's class global, not global). This would potentially eliminate a wire, FGV or private class data value...

 

No price for 'best style', but in a self contained class it usually turns out ok. You can do funky stuff, like catching a value (signaling) in a callback VI, and route it to 0..n other controls with value (signaling), either 'real' controls\indicators, or hacky ones like this.

Message 14 of 14
(201 Views)