Large scale event-driven architecture

[m3nth]

I am developing a large scale application using a central event handler for UI events and calling other code via user events. This has worked fine so far until I ran into a problem documented here:

See Sample VI at the End of This Post

Basically in the event handler, the front panel is locked out on user and dynamic events. Unlike other static events (such as a boolean value change), there is not an option to keep the front panel from locking. Apparently there is no simple workaround for this without changing the structure of the program to not make a process call that needs FP input inside an event handler. (You could use a popup dialog box for input but in my case that's not desirable)

In the post above, there is a link to another article written by one of our very own moderators--actually of interest is a specific section of that article dealing with a consumer/producer architecture:

Archictecture Design Patterns--Producer Consumer with Event Structure and Queues

After reading this, I now have a few questions based on the current design of my program, which is solely event/user-event driven and is not based on the consumer/producer model. This has worked great to date, except now the one instance where I want a process to run in a user event that cannot receive button clicks from front panel (such as the user wanting to cancel that process).

The obvious Pros I see in switching to a consumer/producer would be:

• Fix for the above problem--Ability to process front panel activity inside a working process since it won't be called from the event structure
  
• Removal of the current user-event declarations, which are numerous in my case, cumbersome at best, and require the use of local variables.
  

The Cons I can see would be:

• Reworking lots of events into the new architecture--but that might not be so hard since the old archictecture could remain functional and be phased out slowly
  
• NOT being able to lock the front panel on events called inside of the consumer de-queue loop, which is the default opposite that occurs inside an event loop (I'm just not sure how many problems this might or might not cause).
  

I'm looking for input on suggestions--whether it would be a good idea to try and switch over and whether I'm missing any possible ramifications. Since a lot of the program is already designed, not thinking things through might have not-so-great consequences.

[JackHamilton]

m3nth,

I use a producer - consumer architecture with a mix of event driven queues.

I use a GUI loop and typically put the any User Modal dialog boxes there. I actually have a state in the GUI call "WARN" which can be accessed by a queue message. The command parameter contains the message displayed in the dialog box. The dialog box will only suspend GUI events until the dialog is acknowledged and closed - as the GUI loop is ONLY processing Front Panel User Events - it's ok for it to be suspended - the Processing Loop is actually doing all the work.

This is one of the pitfalls with registering Dynamic Events in the GUI Event structure - you tie the GUI with internal code exection - a No No (IMB).

I don't put any modal VI's or dialogs in the "Processing Loop" this loop is the 'Central Station' where ALL commands are passed to the particular control loop.

I've had applications were commands needed to be received from the GUI, API dll calls, a serial port and TCP-IP - all at the same time. The Processing Loop is the central receiver of these commands.

I tend to keep the GUI loop a simple shell that passes commands to the Processing Loop - the Processing Loop will send a secondary message to the particular hardware/control loop or loops - should a single command require the coordination of several hardware interactions. The processing loop also contains message tracking for debug so I can following all the commands if a problem occurs. Of course each message must contain a sender ID.

I don't use "Dynamic Events" - I know what they do. But I'm sitting on the side-lines waiting for a complelling situation to use them. I seem to be able to handle most problems with my existing architecture. My wish list for dynamic events is to actually assign the Event Structure to poll and fire on the registered event - instead I have to poll the event somewhere else in the code and propogate that to the Event Structure? - seems messy to me. Plus - this is not the purpose of the Event Structure. Back in the day you had huge while loops with tens of controls inside with 100msec delays just to see if the user pressed a button! My Deux those were the days...

Regards

Jack Hamilton