Non-zero default values for reference types

[Yair]

Second model I have been thinking of and playing around but not used yet in real life is using multiple event structures with one event registration refnum, but in such a way that only one event registration refnum is executing at any single time. This way you can switch the way how a certain event is handled by a certain event listener on the fly.

I wouldn't trust it to work, but I have nothing specific to base it on. You can review this thread if you like - http://forums.ni.com/t5/LabVIEW/Register-for-events-causes-freezes-if-used-in-more-than-one/m-p/497567#U497567 . I believe the relevant content starts at reply 14.

[Daklu]

It would be very bad programming not to somehow guarantee that the event is registered before generating the events.

As a general rule, I disagree, though it may be true in your application. The best thing about events is that you can generate as many as you want and it doesn't matter if there are 0 listeners or 100 listeners. If nobody is consuming the event it disappears. I don't have to worry about stale messages clogging up the queue.

The easiest way to do it is simply do the registration outside the process VI that handles the events.

Or let the event consumer component control the life of the event producer component. That works okay if there's a single consumer but gets problematic with multiple consumers. It also couples the event producer and event consumer code more tightly than perhaps you want.

I don't think I'd be comfortable using an event in situations where I had to guarantee a listener is available. The one-to-many nature of events puts the event refnum life in the hands of the signal producer and makes it hard for it to know whether any consumers are executing. What happens if the consumer has an error and abruptly stops? How does it notify the producer of its status change? One nice thing about using queues instead of events for signalling is that since the consumer controls the life of its listening queue when it is no longer executing the queue refnum is released, raising an error at the enqueue prim to let the signal producer know that consumer isn't available. It makes a nice backup mechanism when--for whatever reason--the primary messaging system breaks down.

Second model I have been thinking of and playing around but not used yet in real life is using multiple event structures with one event registration refnum, but in such a way that only one event registration refnum is executing at any single time. This way you can switch the way how a certain event is handled by a certain event listener on the fly.

I do this with queues quite often--multiple loops consuming the same queue with an inherent guarantee that only one is executing at a time. I would *think* it would work for events, but that whole mechanism is rather opaque so all bets are off.