Extent of Coding inside Event Structure cases

[Freelance_LV]

Hi all

I am trying to understand the practices while using an Event Structure. I am used to developing most of my projects using an Event driven State Machine Architecture. Most times, I use Event driven-Queued State Machines. I have also used Producer Consumer Architecture with Event structure driving the producer.

I have always believed that using lots of code, or lots of sub-vis inside one or more cases of an event structure is not a good practice. I reasoned that it will delay the capture of other events occuring while the current case is still executing. This was one of our points during design review, i.e., to reduce the code inside event strucutre cases to as minimal and necessary as possible. We used clusters/queues/LV2Gs inorder to pass on the required data, which will be processed in the other cases/loops.

However, I happened to recently come across a couple of very old applications upgraded to LV2011. The applications used an event structure in one of the while loops, with one or more parallel while loops inside the Main VI. The event structure was the only code in this while loop, no case strucutres.

These event structures had loads of code in each case, with sub-vis and nested sub-vis, even DLL function calls among them. Thats when I started to look for information on best practices using event structures and about any available details on the extent of coding allowed inside an event strucutre.

One sub-vi which was called as a dialog box also had its own event structure (ending up as ensted event structures). I have read about nesting event structures and their disadvantages.

Off course, the code is working and I am not sure if anyone had any execution problems with the applicaiton.

However, I am wondering about the pros and cons of having the entire code inside event structure. I would have defined that code a nightmare. Its disturbing me to see that code and being unable to make it better.

To my understanding, I wish to know if there is any definition or rule regarding the amount of code inside an event structure.

Thank you

[Yamaeda]

Quick and easy: If the event takes too long to execute, you're better off using a producer/consumer pattern.

What's too long? That's up to you. A 1 sec execution time might cause untolerable lag in the UI for some, while other dont mind 5 sec delays (in which case i'd suggest some LED/info text to inform that it's working.

/Y

[Ben]

The exception I use is User driven intefaces where every user action must get a response and each change must complete before the next. In those cases an event only implelmentation is generally fine.

Now if that code does something that takes long enough for the user to question if the program is still alive should at least get a "Busy cursor" OR a progress bar OR an abortable progress bar where the user get s the option to abor out. THe last case may warrent a parallel process to crunch the numbers.

But please keep in mind the above suggestions apply only to those User only" type things. Applcations that invlove the word "while" will generally get deamons and other common design patterns used to henld the implementation. But now I have drifted to design teory and away from the subject so ...

Have fun!

Ben