LabVIEW

cancel
Showing results for 
Search instead for 
Did you mean: 

Event Structures within a Case Structure

Hi,

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?
..

Thanks,

Luca
0 Kudos
Message 1 of 5
(3,062 Views)
Luca Notini wrote:

> Hi,
>
> 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.

This is a very tricky setup! Event structures register for events at the
moment they are present in the diagram. Depending on some settings such
as locking on events you could create situations where your applicaton
will lockout itself completely.

In general it is not a good idea to have more than one even
t structure
in a single diagram.

Rolf Kalbermatter
Rolf Kalbermatter  My Blog
DEMO, Electronic and Mechanical Support department, room 36.LB00.390
0 Kudos
Message 2 of 5
(3,061 Views)
> 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 ev
ent, 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
Message 3 of 5
(3,061 Views)
Thank you for the reply,

All the event structures would be handling the different events.
In each dialog tab in my FP there are a selection of options which are
relevant to the data being displayed within that tab, I have also nested
tabs. You are correct Greg in that I can do all I want to do using multiple
event cases in one event structure. The reason I thought about doing it in
the way suggested in the previous post are twofold.

1. The method, if it worked, would result in a more intuitive diagram that
refelected the structure of the GUI.

2. The number of events required to be detected would be minimised to those
that are relevant to the tab currently displayed.

Luca



"Greg McKaskle" wrote in message
news:Vg0tc.479$4x2.386@fe2.texas.rr.com...
> > 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
>
0 Kudos
Message 4 of 5
(3,061 Views)
> 1. The method, if it worked, would result in a more intuitive diagram that
> refelected the structure of the GUI.
>
> 2. The number of events required to be detected would be minimised to those
> that are relevant to the tab currently displayed.
>

If you wish to do this, it is possible, but it will require you to use
dynamic registration. Statically registered events are always enqueing.
The dynamic registration means you can change what object is
registered and when it is enqueing. You might want to look at the
examples ofr dynamic events first as it gets a bit more complicated.

Greg McKaskle
0 Kudos
Message 5 of 5
(3,061 Views)