Generate user events by name?

[Intaris]

---

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.

[wiebe@CARYA]

---

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

[Intaris]

---

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.

[wiebe@CARYA]

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

Make a VI with (Boolean) controls:

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

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.