Boolean controls don't respond to input when inside an event in the event structure

[eric 206]

I am using an event structure inside of a while loop in LV 6.1 and the events are occurring the way that I want them to. The problem that I am having is that when executing inside a specific event, the entire front panel does not respond until the event is completed and exited (i.e. I click on stuff and nothing happens) I've added lots of pauses to give the cpu time to respond, but it doesn't help. I've changed mechanical actions, I've changed events, event sources, etc but nothing seems to help.

It seems like the event structure is designed to operate this way, which is weird. I've even managed to crash Labview by clicking too many front panel controls while it is in an event.

Has
anybody else noticed this problem? Is this a bug in the event structure? Or am I just doing something fundamentally wrong with the event structures?

Thanks,
Eric

[viScience]

I am afraid that is the intended behavior. Events lock the front until
processed. If you need to get around that you can look at an example of
using queues in event structures at www.openg.org

Mike Sachs
Intelligent Systems

"eric" wrote in message
news:506500000008000000894F0000-1023576873000@exchange.ni.com...
> I am using an event structure inside of a while loop in LV 6.1 and the
> events are occurring the way that I want them to. The problem that I
> am having is that when executing inside a specific event, the entire
> front panel does not respond until the event is completed and exited
> (i.e. I click on stuff and nothing happens) I've added lots of pauses
> to give the cpu time to respond, but it doesn't help. I've changed
> mechanical actions
, I've changed events, event sources, etc but
> nothing seems to help.
>
> It seems like the event structure is designed to operate this way,
> which is weird. I've even managed to crash Labview by clicking too
> many front panel controls while it is in an event.
>
> Has anybody else noticed this problem? Is this a bug in the event
> structure? Or am I just doing something fundamentally wrong with the
> event structures?
>
> Thanks,
> Eric

[Greg_McKaskle2]

> I am afraid that is the intended behavior. Events lock the front until
> processed. If you need to get around that you can look at an example of
> using queues in event structures at www.openg.org
>

The panel is locked to avoid race conditions between what your diagram
is trying to accomplish and what the user might be doing. If you are
going to gray or show/hide a control, you do not want the user's actions
to be interpretted until your diagram finishes responding to the
original event.

If you are familiar with how computer interrupts are handled, it is very
similar. However, if your diagram isn't doing anything that is in
conflict with the user's actions, you can turn off the panel locking for
an event when in the configuration page fo
r the event.

You probably also want to look at the event examples in
examples/general/uievents.llb, and at the ones posted previously.

Greg McKaskle

[vt92]

Any code that is inside a specific event has to complete before LabVIEW will handle any additional events.

If you submit your code, we can give you a more definite answer to your question.

[eric 206]

I wouldn't really expect additional events to be handled until the current event is complete. But I need to be able to use the front panel from inside of an event.

The attached VI, "Wf Level DT.vi", has the mentioned event structure and it is the "Auto Test" Mouse Up (I've also tried Value Changed) event that I am most concerned with at this point. There is a while loop within this case that uses a front panel boolean ("Stop") as a stopping condition. However, the button can never perform its required task the way it is now.

Am I doing something wrong here? Is there a way around this problem? I am having trouble finding any documentation on this issue. It seems that I need to re-think the way I am doing things, but I do not want to abandon the
event structure since it is convenient in many ways.

Any advice, tips, or help on this issue would be really appreciated. Thanks.

Eric

[vt92]

I see what you mean. I highly recommend using a Queued state machine, like the other person suggested. See http://openG.org/

This is a 'psuedo' object oriented approach that will free the working part of your code from the user interface and get rid of the problem you are having. I also suggest you give the stop button its own event case.

[Jeremy Braden]

I ran across this problem before with stopping a loop inside of an event. Try to right click on the title bar of your event and slide down to unselect "Lock Panel until Handler Completes".

Jeremy

[eric 206]

Thanks for the help. I unlocked the panel for several events which allows for the user to exit the while loop. Also it seems that in doing it this way, Labview uses its own FIFO queue to handle the events one at a time. It works just like I need it to and I think I'm going to try it this way. I just wonder what possible dangers are presented in doing it like this.

Thanks again for your help.
Eric