> In order to achieve what I want to achieve I have thought about the > following approach. My diagram would contain multiple event structures each > of which are handling multiple events. Each of the event structures are > contained within a Case structure such that theoretically events are being > handled by only one event structure at any one time. The specific Case that > is selected is controlled by the value of a Dialog Tab. > > Is this a valid approach? > .
As Rolf stated, probably not. When a panel opens or gets reserved, the queue is created and registered for the various events. This ensures that you won't miss an event just because you aren't waiting on the event structure. But if your multiple event structures are waiting on the same event, then both must execute to handle it. So, why are you placing your event handling code in multiple event structures? A more common architecture is to have one loop doing UI processing, I call it cooking the events, and posting higher level or cooked events to a second structure. This second structure can be a loop/case queued state machine, or a loop and event strucutre that only registers for user events. This approach can usually be collapsed down into a single loop, but some prefer to keep them separate. If you describe more of why you want the event structures in different cases, we can give alternatives that make more sense. Greg McKaskle
