Clear indication of handled User Events

[Intaris]

When working with User Events as an API between modules there is a nasty little thing which unfortunately keeps rearing its ugly head.

If we retrieve a cluster of User Events (or an Event registration refnum) from a module with events we should be listening to and wire this to an event structure we get a memory leak if not all events are handled.  This particularly occurs whenever the API is extended and not all listeners have been updated.

It would be much easier to track down these kinds of problems if the Event Structure would display which User Events are in the associated Registration Refnum but are NOT yet handled.  This would be a great too in tracking down rogue Events and eliminating possible memory leaks due to implementation errors.

Currently one has to iterate through ALL of the user events and observe the warning "this event is handled in another case" in order to find out if all have been handled or not.

[AristosQueue (NI)]

Useful suggestion. Kudos!

[X.]

I am not familiar with this leak issue, but a related suggestion would be to differentiate between events (not just user events) which have a case handling them and those which don't.

Currently, you have to try creating a case for an event which is already handled to get a warning that this event is already handled in cas nnn.

Maybe a color or style cue?

[Intaris]

The memory leak doesn't occur with static events because adding it to the Event structure (emptying the mailbox) does the registering (creation of the mailbox) for the event automatically.  Therefore if it's not in the Event Structure, it's not registered (and there's no "mailbox" for the event - heads up to Jack for that analogy BTW).

For User Events however the registration must be done separately and there can then be a disconnect between the registered events (creating a mailbox) and the handled events (emptying the mailbox).  Note that registered but unhandled events WILL store all events in a buffer - Any mailbox which exists will continue to store any mail sent to it until it is emptied of LabVIEW runs out of memory).  This is a memory leak.

[Intaris]

So, apparently the workings of all of this has changed......

https://forums.ni.com/t5/You-May-Not-Know/Be-Careful-What-You-Register/ba-p/3569679

As of now any event queue represented by a registration refnum which is NOT HANDLED by an event structure it is wired to will be emptied .  While this gets rid of the memory leak problem, it's really a "solution" I'm not fond of at all.

While this change in internal behaviour does not remove the need for my idea, I feel that the goalposts have shifted quite unexpectedly significantly.  The fact that an event structure will now empty any such event unhandled event queue probably makes this idea even more urgent...... Instead of being notified in order to avoid memory usage we need to be notified to avoid possible data loss.