Why does the Generate User Event function require 'event data'?

[ajbradford]

Good afternoon, I'm working through Core 3 learning about Dynamic User Events. It seems redundant to me that the Generate User Event function would require both the user event refnum and a data type wired into 'event data' which would have been needed to create the user event refnum in the first place. Why isn't the refnum alone sufficient to identify the proper user event to be generated?

Here's the documentation I can find: Generate User Event Function - NI

[raphschru · Accepted solution]

Hi,

"Generate User Event" is used to trigger / send / fire your event, so the terminal "event data" is simply the data you want to pass to the event structure that will register for this event.

As you have understood, the data type is already defined when creating the user event.

Now when generating (= sending) your event, you need to provide the actual payload data (of the same type as defined earlier).

You can look at the example "User Event Generation.vi" (go to Help > Find Examples... > Search).

Regards,

Raphaël.

[ajbradford]

That makes sense. Thank you!

I wonder then - from NI's perspective, why not make the 'event data' input recommended instead of required and default the payload to the actual value provided when creating the user event? I understand that would make the value of the 'user event data type' input meaningful when creating the event, but that seems to be an improvement.

[raphschru]

---

@ajbradford wrote:

why not make the 'event data' input recommended instead of required and default the payload to the actual value provided when creating the user event?

---

It could have been that way, but if you look at other similar synchronization objects (Notifier, Queue, ...), they all follow the same principle:

1. Create a "typed refnum" from a user-specified data type;

2. Send data of the same type as defined at creation;

3. Destroy the refnum when not needed anymore;

It would be weird to e.g. send a message to a Queue without specifying the actual message to be sent.

Also, it would require that LabVIEW stores that default value somewhere in memory, making its implementation more complicated. More complicated objects are less generic and the purpose of a User Event is just to send an event to event registration queues, not to store a default value persistently. There are other mechanisms made for that (shift registers, global variables, FGV, files, ...).

[ajbradford]

Makes perfect sense, thanks!