unbundle registered events

[Norbert_B]

---

@Intaris wrote:
Norbert,
[...]Why do we have the event refnum exposed here?

Shane.

PS Forgot to add: LV 8.2.1


Message Edited by Intaris on 06-02-2008 10:32 AM

---

I am not sure if this is really the case, but it is possible to use this Refnum to destroy the event. This does not make too much sense because for a dedicated shutdown procedure, it is required to unregister for the given events before clearing them up. But you could unregister and re-register for this event for instance with this.....

Norbert

[Intaris]

To be honest, it seems to me that the event refnum should NOT be available here.

I'll refrain from shouting bug if someone can give me a good reason why the event fired from a "Register for Events" function exposes the actual event refnum.

But we can unregister already by setting the vlaue of the terminal in the "Register for Events" to a null refnum.  We don't need the actual event refnum for that at all, do we?

For me, they should either be generally available or not at all.

Shane.

[Norbert_B]

---

@Intaris wrote:
[...]But we can unregister already by setting the vlaue of the terminal in the "Register for Events" to a null refnum.  We don't need the actual event refnum for that at all, do we?
[...]

Shane.

---

You need it, if you want to re-register it again in the same event.......

[Intaris]

Norbert,

But if I set it to null, then the event is no longer available in the event structure surely.

If I set (within the event structure) a specific event to null via the register for events structure, the original reference is then no longer available (not least because the event can no longer fire, and the event is only exposed WITHIN the event case).

Please tell me if I have misunderstood something,

Shane

[Norbert_B]

Shane,

attached screenshot will work without creating any errors. The reason is, that the existence of events does not depend on its registration. Using registration, you only prepare the eventqueue to potentially dequeue elements of this event type. If you have not registered for this event type, i would say that it even isn't enqueued, but i don't know for sure....



I must admit that my example is a very rare case of usage, if it is used at all, but it is possible....

Norbert


Message Edited by Norbert B on 06-03-2008 03:38 AM

[Intaris]

Norbert,

isn't the code you posted a no-op?

You're bascially unregistering the same event you're re-registering......  Just because it doesn't throw an error, doesn't mean it makes it neccessary.

Is there some reason why this may be required?  According to my knowledge, the UsrEvtRef available within the event structure is exactly the same as the one you are trying to unregister and re-register.

I'm aware the events and the registrations are different things.  This is why the presence of the refnum in this position is, for me, unneccessary.  In fact, I'd almost prefer it to be NOT available.  Then we have a real read-only situation when we pass a Reg Events wire to a VI.  The VI has NO way of getting to the actual events behind the event handler...... At the moment, any VI receiving a wire of pre-registered Events can fire any of the events it receives.  It is possible to buffer all event references received and then fire them whenever needed.  This would, IMO, weaken the usage of passing a pre-registered group of events to a sub-VI.

Shane

Ps what I meant by not being available when set to null was referring to the unregister and re-register being in different frames of the event structure.


Message Edited by Intaris on 06-03-2008 03:46 AM

[Norbert_B]

Shane,

as i already wrote, this could be done, but is a very rare case...

---

@Intaris wrote:
Norbert,

isn't the code you posted a no-op?
[...]

Shane

---

One example where this could be useful (perharps):
Image a continuous running loop creating a user event. A "consumer" reacts on those events. Now, due to different external infos, the event case could take very different amounts of time for execution. Since the "producer" still generates the events, you would maybe enqueue many events which are not of interest anymore. So maybe you want to unregister the user event in cases of long executions within your consumer. But after the execution of the event-case has finished, you want to re-register the event to continue working on them....

Sure this is quite abstract and virtual, but possible. Nevertheless, you are correct that there is no really obvious reason for the eventstructure to expose the user event reference.

Norbert

[Intaris]

Norbert,

OK that's a fair and logical use of the refnum.  It's kind of like the option for UI events to block the front panel then......

I still, however, think this refnum should NOT be available here.  I would prefer an option for the event case "Don't accept further events until finished" to keep it in line with the options for the UI events.  This way, the user does not get to decide themselves what they want to do with the event refnum.

Thanks for the example though.  It's basically the only situation where I think it would make any sense.....

Should I file a bug for incorrect behaviour?

Shane.

[Norbert_B]

---

@Intaris wrote:
[...]
Should I file a bug for incorrect behaviour?

Shane.

---

I doubt that this is considered to be a bug. It is more likely a product suggestion since i think that LV acts like this since user events were introduced....

You can file suggestions using the Suggestion Center.

thanks,
Norbert