Bug in Dynamic Event Registration

[Wolfram]

In LabVIEW 2010 SP1 is ok. In LabVIEW 2011f2 NOT ok.

Open and run the attached VI first in LV2010SP1, then try in LV 2011f2.

Greetings

Wolfram

BugReg.vi

[Ton Plomp]

I'm not sure if this is a bug. You unregister the ERF, and then you use the same ERF to register new events.

Here's a quote from the help:

Event structures which use this event registration refnum no longer receive any dynamic events.

So it sounds like it's a dead ERF...

What really buggy is that it locks up the UI whenever I click one of the buttons.

Ton

[mje]

The UI lock is indeed weird.

After you unregister an event registration refnum, I'm not sure if you're supposed to be able to reuse it. I'm under the impression the way one usually handles dynamically registering/unregistering events is by using null refnums for unregistration:

Dynamic Registration LV10.vi

[Wolfram]

What I mean is the difference in behaviour between LabVIEW 2010 and 2011. In 2011, the VI hangs. But there is also another solution: If you replace the tunnel with a shift register, you can execute the Unregister For Events.

BugRegShiftReg.vi

[Mark Smith]

The UI lock is indeed weird.

After you unregister an event registration refnum, I'm not sure if you're supposed to be able to reuse it. I'm under the impression the way one usually handles dynamically registering/unregistering events is by using null refnums for unregistration:

Dynamic Registration LV10.vi

I just ran into this issue with some code I wrote in LV10 and then tried to run in LV11. This thread proved most useful as MJE's solution worked exactly as advertised, so a big thanks and kudos! But I have to ask, the idea of NOT using a function called unregister for events and instead using null refs to ... you guessed it ... unregister for events seems like some pretty arcane knowledge. Where did you get this tidbit of information?

Thanks,

Mark

[mje]

I just ran into this issue with some code I wrote in LV10 and then tried to run in LV11. This thread proved most useful as MJE's solution worked exactly as advertised, so a big thanks and kudos! But I have to ask, the idea of NOT using a function called unregister for events and instead using null refs to ... you guessed it ... unregister for events seems like some pretty arcane knowledge. Where did you get this tidbit of information?

I'm glad the example proved useful. Not sure where I got that trick to be honest. Probably stems from my use of events in other languages.

The way I see it, the Unregister For Events operates on all dynamic events that are used by the event structure. True, for the simple case I posed above, using the unregister primitive can work if you start using shift registers, but only because every dynamic event handled by the structure is related to the example.

Consider extending the example: I want to receive notification from user event as well, all the time. To unregister for the two events posted in the above example but not unregister for the user event, I have to use null registration. If I call the unregister primitive, I'll end up unregistering for my user event as well. Similarly using the global unregister primitive doesn't work if you have different dynamic events with different lifetimes. Maybe you want one of your event registrations to last indefinitely, but another one times out or cancels itself if a certain piece of data is received?

I'm not saying the unregister primitive doesn't have it's place. There's still exactly one unregister primitive for each registration primitive I use in my code, it's just that the unregistration is usually left for a shutdown sequence.

[Ton Plomp]

The trick is shown in the example: \general\dynamicevents.llb\dynamically register for events.vi.

Ton

[Mark Smith]

It seems like every time I look in the LV examples I can't find what I need and every time I don't look the answer is there waiting for me. Oh well, I'll know to check next time.

Thanks,

Mark