Nugget of the week: Dynamic event registration

[Neil.Pate]

Thanks for your comments tst,

I found the solution to my problem...

My project hasa bunch of code outside the main loops doing initialisation and things that could not be put into the main loops, primarily due to it being related to registering of events.

I finally got around to consolidating the various VIs into a single Init VI, but mistakenly forgot that I had a Set Cursor Busy as one of the first few steps.  This primitive throws an error if it is inside a subVI and the panel is not loaded (ie a pure subVI), so this explains why it was working when I had the subVI open to debug (this is not the first time I have made this mistake! D'oh!). Simple enough to fix...

I still dont really understand the wording of the LV help about the event registration as to me it implies the event stops when the VI that registered it stops running, not the hierachy. It does seem to work fine though, so I will not worry too much about it.

None of my user events are FP/UI related. I have several different events from various bits of unrelated components. A large source of my events are callbacks generated inside DLLs, so there are quite a few layers of abstraction in my code, I do not want to do the event registration "near" the main Event handler as to me it makes the code look messy and there is a lot of it! I know its a pain passing around event references (or bundles of them) as they break really easily, but cannot really think of a simpler way. A FGV would probably suffer the same problems...

Attached is a capture of my Initialise (outside the main loop) subVI.

I have a task scheduler which generates User Events to fire off certain tasks at a periodic rate.

The parent VI of this is my top-level VI, and I take the Event Registration Refnum directly into the dynamic terminal of a Event Structure.

I wish we could reliable chain together Event Registration primitives, but from what I have read on the forum this does not always work perfectly.

Can you think of a better/simpler/more efficient way of doing this???

[Intaris]

---

@tst wrote:

In any case, passing event registration refnums around is a BAD idea. Generally, Reg for Events nodes should be right next to the event structure getting the event reference. If you want to register for an event on a control in a subVI, pass the reference to the control out of the subVI and then register for it near each event structure where it's going to be used.

---

I don't think it's a bad idea at all.

I'm not looking to start a discussion on it, but I want it on the record that I personally think that passing registration refnums can be a perfectly valid way of doing things and has some important advantages over passing control refnums or event refnums around.

Shane.

[tst]

---

nrp wrote:

I wish we could reliable chain together Event Registration primitives, but from what I have read on the forum this does not always work perfectly.

---

Well, the reg node does have a reference input, but that reference sets which events it can handle. If you want to register for a bunch of events as a single module and then use an event structure to register several of these modules, you can bundle the registration refnums into a cluster (near the structure) and wire the cluster into the event structure. It will give you access to all the events:

[tst]

---

@Intaris wrote:

I don't think it's a bad idea at all.

---

In that case, let me rephrase it - every event registration refnum should go to a single event structure. The best way of ensuring this is having the registration node near the structure. If you don't have it near the structure, you should be careful. There are ways of increasing the safety (such as using a reentrant subVI to generate the references), but you need to remember to use them.

[Neil.Pate]

---

@tst wrote:

---

nrp wrote:

I wish we could reliable chain together Event Registration primitives, but from what I have read on the forum this does not always work perfectly.

---

Well, the reg node does have a reference input, but that reference sets which events it can handle. If you want to register for a bunch of events as a single module and then use an event structure to register several of these modules, you can bundle the registration refnums into a cluster (near the structure) and wire the cluster into the event structure. It will give you access to all the events:

---

This is similar to what I do, except I register clusters rather than bundling the registered events. In your example some code still has to register the events, where would this be done, on the root of the top-level VI? If there are lots of User Events (i.e. > 10) then that code is going to take up a significant portion of the top-level BD and does not really belong there IMO.

My architecture has a single main Event Handler running on the top-level to deal with User Events and UI Events.

I think its unfortunate that the Reg Event has to be strictly typed to get the Event Structure to show the events properly, as this leads to lots of fragile code during development. This leads directly to the inability to chain together multiple Regiser Event primitives which would be nice if this could be done I think...

[Intaris]

---

@tst wrote:

In that case, let me rephrase it - every event registration refnum should go to a single event structure. The best way of ensuring this is having the registration node near the structure. If you don't have it near the structure, you should be careful. There are ways of increasing the safety (such as using a reentrant subVI to generate the references), but you need to remember to use them.

---

Aye.  I can agree 100% with that post.  One event registration refnum per event structure.

[tst]

---

@nrp wrote:

In your example some code still has to register the events, where would this be done, on the root of the top-level VI?

---

Look at the discussion Shane and are having. You can move the registration into modules in subVIs. Just make sure that every registration refnum gets to a single structure. For something like this, bundling the reg refnums is useful.

---

I think its unfortunate that the Reg Event has to be strictly typed to get the Event Structure to show the events properly, as this leads to lots of fragile code during development.

---

That's the nature of the beast. The settings on how to handle events in the structure have to be set at edit time, and for that you need to know which events you can have. You can make this partially dynamic by passing variant data (such as a variant or an object) into a shared event and using to determine what to do. Shane had a nugget demonstrating this.

[Intaris]

I think the nugget Tst is referring to is HERE.

Shane.

[devicx]

Hi All,

Reading through the latest set of postings on this thread reminded me that there's an interesting (and fairly "large") piece of code provided as of LV 2009 that demonstrates a number of the ideas just touched upon. (Those who don't already know of it will soon surmise that it is the code for the icon editor.)

It can be found here: <LV 2009>\resource\plugins\lv_icon.vi

Anyway, thanks for posting your thoughts here. They have provided much pabulum (and cleared out some dustballs from between the ears).

[aliasThree]

Yes, this is a great thread! Actually the front panel only has to be open during dynamic event registration. In a sequence, I open the panel, in hidden mode, with a method, then execute the Reg Events node, then close the panel. The way my app is structured, this only happens at program start, so I can't say there aren't other considerations for other scenarios.