Named User Events? - NOT using labels

[GR LV]

Why do user events require the event name be pulled from the label of the item wired to the create user event VI? I am looking to use user events which the name of the event may be wired separately to the create user event and register for event VIs.

If I have a data store with 1000 variant items in it. I want to create an "on change" event for each item in the data store. All of the items have the same data type.. a variant or some cluster of info.. and a different name. Other tasks can then watch for a specifc item to change by registering for an event with the same name and type. However, I certainly do not want to waste my time creating 1000 constants of the same type just to wire it to the create user event VI. (The actual names in this application may be built at runtime) I also do not want the tasks to have to watch for a common event that triggers whenever any item in the data store changes and then have to filter out what is relevant to the task. (this wastes resources)

Why can't the user event and register for event functions just use the type of the data and let the name be passed in separately like queues do??

Can NI provide me a simple patch to do this?

[MikeS81]

Hi GR_LV,

if you want to register for all events, then read all your control references with a property node and connect the result array to the event registration. See the attached image.

There is also a great nugget about the event registration topic.

Hope it helps.

Mike

[F._Schubert]

I hope I get your intention right.

Why it isn't possible:

Because you would need to create the code (event structure frame) to handle the run-time created event type (event queue) during run-time.

What you can do:

* You can use a single type of event with some extra data (e.g. a string) that conforms to your 'run-time created type'. Then the event structure needs to parse the event type and perform the appropiate action

* Do it the LVOOP way: The event is a class. The event class and it's sub-classes have a method how the event should be handled. This would be called inside the event frame. Now you have your event handling code inside the class, get the correct method invoked by dynamic dispatching and this all during run-time.

If it's just about the name of the event structure during coding, you can use a type cast to name the event.

Felix

[GR LV]

"if you want to register for all events, then read all your control references with a property node and connect the result array to the event registration. See the attached image. There is also a great nugget about the event registration topic."

This doesn't work because I don't have controls or indicators to generate the events. It is a data store (repository) of stuff created various ways. Think of it as a functional global of data. There is a write case when you write data to the repository. I want to create a user event when that data is written that is unique to the name of the item being written. There is not a control for each item in there. That is specifically what I want to avoid doing (creating design time controls) because the name of the data is dynamically built at runtime.

[GR LV]

* Do it the LVOOP way: The event is a class. The event class and it's sub-classes have a method how the event should be handled. This would be called inside the event frame. Now you have your event handling code inside the class, get the correct method invoked by dynamic dispatching and this all during run-time.

If it's just about the name of the event structure during coding, you can use a type cast to name the event.

I'm not sure I follow either of these..

Not sure how type casting would affect the event name..

You wouldn't be able to whip up some pseudo code would ya..

Here's what I want to do..

[MikeS81]

Hi GR LV,

is using only one event ok for you? You can generate this event everytime you write data into your buffer. If your event is of the type string, the you can send whatever data you need with the event (name, value, ...).

Mike

[Ben]

rather than pounding on an event structure to change it's shape, how about using "named queues"?

Instead of the event in a loop you check the queue in a loop and if there is something there handle it like it was the event. You can set it up to either do it witha zero timeout (polling) or the loop can sit at the "Dequeue" until something is pusshed to the queue.

Ben

[F._Schubert]

The type def is created as a constant via right-click menu on the wire coming from Create User Event. Just the label changed.

Felix

[GR LV]

"is using only one event ok for you? You can generate this event everytime you write data into your buffer. If your event is of the type string, the you can send whatever data you need with the event (name, value, ...)."

This works, but I'm concerned about the performance hit / scalability of waking up every single task for no reason whenever anything changes just to realize it's of no interest and go back to sleep. Lets say there are 25 tasks. Each task is registered for one of 1000 items. Higher rate data may be changing which none of the tasks are interested in... Not very efficient to have one common event. 

"rather than pounding on an event structure to change it's shape, how about using "named queues"?

 Instead of the event in a loop you check the queue in a loop and if there is something there handle it like it was the event. You can set it up to either do it witha zero timeout (polling) or the loop can sit at the "Dequeue" until something is pusshed to the queue."

The current implementation is named queues. Yes this works, But what am I doing.... Using a queue to implement an event........ (why should I have to do this?) If you call a generate event and nobody is registered, nobody cares. You have to add logic to determine if you want to put an item on a queue in case nobody is listening so that you don't build up the queue..

"The type def is created as a constant via right-click menu on the wire coming from Create User Event. Just the label changed."

This is an interesting trick.. However, it still requires me to create a constant with x unique names. I guess I will have to do some testing to see if the events created in a loop are unique, but have the same name, or are truly the same event with unpredictabel results for creating many with the same name. (unless someone already knows the answer) ... If they are truly unique, but have the same name, I could use this for tasks that register for only a few items... Still rather cumbersome for tasks that need to register for many.

[Ben]

---

@GR LV wrote:

...

"rather than pounding on an event structure to change it's shape, how about using "named queues"?

 Instead of the event in a loop you check the queue in a loop and if there is something there handle it like it was the event. You can set it up to either do it witha zero timeout (polling) or the loop can sit at the "Dequeue" until something is pusshed to the queue."

The current implementation is named queues. Yes this works, But what am I doing.... Using a queue to implement an event........ (why should I have to do this?) If you call a generate event and nobody is registered, nobody cares. You have to add logic to determine if you want to put an item on a queue in case nobody is listening so that you don't build up the queue..

...

---

Jim Kring (co-author of LAbVIEW for everyone) posted this design pattern that I in turn used as inpiration for an in-house pattern we used called "Self-adressed Stamped envelope" and is used when we have an unkown number of subscribers tht may or may not want to get updated when new data comes in.

THat approach will let me attach anything to anything (as long as its on the same machine and running in the same conext) but only the data that has to be shared and no more.

Ben