missing events if two event structures simultaneously listen to the same event

[stoeckel]

Hi folks,

a situation that might occur easily while programming a somewhat bigger application: Two event structures that may exist in different vis listen to the same event, e. g. a value change of a control on the user interface panel. As the experiment shows events may go lost occasionally in one or the other event structure. See the attached test vi. If you hit the "Next Event" button repeatedly and fast enough, you'll see that the two event counters start to differ. Obviously, an event structure may miss an event if it is swallowed by the competing structure while the losing structure is idle due to time-out. However, setting the time-out of the two event structures to -1 does not solve the problem. 

Is there any way to circumvent this shortcoming? How can I make sure that none of the two event structures will miss any event?

Thanks for any contribution.

Peter

[MikeS81]

Hi Peter,

don´t wait on this event in two event structures. If you need this functionality, then you can use notifier.

Mike

Message Edited by MikeS81 on 08-22-2008 02:26 PM

[Ben]

Hi Peter,

I hope you did not expect a short and sweet answer to a subject like this.

Please read this thread where Jason from NI R&D (and many others) discuss this same topic.

The "Reader's Digest" answer is use seperate registrations for each Event Strtucture. The registration wire can be thought of as a queue (well not really, read that thread) where if you want the event to show up more than one place then use a unique registration for each.

Ben

[Norbert_B]

Peter,

i cannot say that this behaviour is "works as intended" or a "bug". But using two different event structures in application is general not a real good idea, and having both of them using the same event(s) shows a large lack of planning in the design phase of the project. Even if you don't want to pronounce it that harsh, it will still show a lack of definition of interfaces (UI, instruments, shared resources, ... ) and therefore still points to the designphase......

So if you want to really solve the issue, you have to eliminate the second event structure or, at least, eliminate "duplicated events". This is the only way to get a proper application.....

See more caveats of the event structure here

hope this helps,

Norbert 

EDIT: Very good link, Ben...haven't seen this before. So taking this into account: Behaviour is as expected..... 

Message Edited by Norbert B on 08-22-2008 07:41 AM

[Ben]

---

Norbert B wrote:

Peter,

i cannot say that this behaviour is "works as intended" or a "bug". But using two different event structures in application is general not a real good idea, and having both of them using the same event(s) shows a large lack of planning in the design phase of the project. Even if you don't want to pronounce it that harsh, it will still show a lack of definition of interfaces (UI, instruments, shared resources, ... ) and therefore still points to the designphase......

So if you want to really solve the issue, you have to eliminate the second event structure or, at least, eliminate "duplicated events". This is the only way to get a proper application.....

See more caveats of the event structure here

hope this helps,

Norbert 

---

Sorry but I have to split hair Norbert.

The thrid from that last bullet in your link addresses multiple dynamic event registrations.

A very simple example that would use multiple events registrations for the same object could be;

1) Many controls are required to change there background color if the value goes over 75%.

2) One or many of those controls must send an e-mail if they go over 80%.

To handle #1 I could spawn off a bunch of background VI from a template and pass each a ref to the controls they are supposed to monitor for color change.

To handle #2 I could use a similar approach.

Using that approach I only have to write two VITs and call them with the proper parameters.

Or did I miss the intent of your post?

Ben

[gchristi1]

Look up the nugget on dynamic events. After reading TomiM's response, I was able to go in to your vi and fix it.

[Norbert_B]

 Ben,

interesting example. I would actually go straight forward using a single event structure capturing the events and "filtering" them in order to know how to react.

So i am very interested in a small example for your VITs. Maybe you can start with the attached VI....

Norbert 

[Ben]

Norbert,

I do not have time to play today but one of my customers has been urging me to write-up his application as a Nugget. When I get around to that one, you MAY* see an example where four background VI's (each responcilbe for a seperate PID) will register for events on the "auto/Manual" button.

Ben

* MAY = I may drop that part of teh code from the Nugget since the extra background PID's VI's could detract from the Nugget's intent "E UNUM, PLURIBUS"

[Norbert_B]

---

Ben wrote:

Norbert,

I do not have time to play today [...]

---

That somehow makes me sad since discussing with you is interesting and improves my knowledge on LV.

Nevertheless, i spent a couple of minutes on thinking on any real "it has to be done like this" example... and i have to say, i somehow cannot get away from my way to do it:

There is one event structure for all controls on the UI. If i happen to have something "triggered off" by a e.g. a button, i always prefer to use queues or notifiers to inform the recipients of the event rather than the event itself....Queues if having the requirement not loose any data and only having a single recipient, notifiers to inform several recipients and the possibility to "lose data".

So the only chance to get me to other "formats" would be several recipients and the requirement not to lose data.

Then i would first of all think about the recipients:

- Why the heck do all have to get the same messages without losing data? This is definitly redundancy, making the code hard to read and debug.

- If this is the only "shared event" and the recipients react differently, "spreading" the event is ok. But i would think if all recipients have really to share the same transfermechanism or not....if not, use a dedicated queue/notifier for each recipient

Well, this is what comes in my mind after thinking about this a while. Maybe, i am a bit simple minded here, but we are all up to improving our skills as well as style. Therefore, if there is a more elegant way, i am eagerly waiting for your nugget...

Norbert 

[Intaris]

You need to think of modules.

Flexibility can be achieved by using parellel processes which have registered for events.  You can even launch multiple processes for a single control if they use register for events.

By modularising the code, complexity is greatly reduced and re-usability is greatly improved.

For a recent project I developed a background process to monitor an XY-Graph, allows selecting areas of the graph (With visual feedback of course) and raises a user event with the selected data.  If I ever need this functionality again, I just drop it into a program and hey presto it works!

If you're dealing with a one-off monolithic piece of software, design can solve the problem, but registering for events gives so much freedom regarding encapsulation, cohesion and general modularity (without requiring OO) it'sgreat!

Shane.