Event structure with controls disabled and grayed out

[Doug_C]

I'm working on a DAQ program that uses the event structure to handle the GUI.  I have a "start logging" button that triggers an event when the value changes and begins collecting data.  While collecting data the program disables and grays out all of the controls on the front panel except the "stop logging" button which ends a while loop with in the data logging event.  So this event is active until you press "stop logging."  There are other events that are triggered by a mouse up/down action of the other disabled controls on the front panel.  The problem is that while the program is collecting data if you click over one the disabled and grayed out controls that has a mouse up/down event, the program seems to lock up and won't allow you to press the "stop logging" button.  I don't know if its trying to run the other event but it does continue logging data, I just can't stop it.  I have to use the abort button to stop the program.

The real issue is that a control, even when disabled and grayed out, can still trigger a mouse up/down controlled event, is this true?  Also what happens if one event is triggered while another event is running, it was my understanding that only one event can run at a time.       

Thanks

Doug 

[Ben]

1) Your GUI is probably locked-up because you have left the default setting on those events as "Lock FP..." = TRUE. Try disableing that setting.

2) A Master-Slave architecture will let you sperate  your GUI rom the DAQ stuff, you may want to concider changing things. (see Lynn's reply for more on this idea)

3) The events firing for disabled-and greyed out is a useful feature once you know they still fire. They let you present a pop-up saying "This control is greyed because you did not login!"

Just trying to help,

Ben

Message Edited by Ben on 12-18-2008 10:39 AM

[johnsold · Accepted solution]

Doug,

Reading between the lines here a bit....  It sounds like you have your data collection and logging code inside the Start Logging event case.  If so, that is part of the problem.  No other event case can execute until that one is finished.  Move the data collection and logging code to a parallel loop.  Have that loop sit in an idle state until the Start Logging button is pressed.  Then in the event case for the button change send a command via a queue to the logging loop and exit the event case.  The vent loop is then immediately ready to respond to the next event.

Generally speaking the code inside an event case should run quickly, no more than 10s of milliseconds to perhaps 100 ms to avoid a sluggish response to another event.

Look at the Producer/Consumer (events) design pattern which ships with LV for an example. 

Lynn 

[Doug_C]

Thanks for the quick responses.  Ben, I already had made sure the "lock FP" checkbox was unchecked on my "start logging" event.  Lynn, I think you have the best solution, but I have sort of run out of time to make that large of a change plus I would need to learn how to use a queue.  So I have another question. 

The main reason I used the mouse up/down event triggers was to have one event run right before another.  So in my program one event is triggered by the mouse down of a button and another event is triggered by the value change of that same button.  I know this probably is not the best practice, so does anyone know a better way to accomplish one event running right after another with one button press?

[Ben]

? Value-Signalling property node (of control that triggers second event) in first event is written to trigger second event ?

?

Ben

[TCPlomp]

You should unceck the FP-lock option in every event case.

And you should keep the golden rule:

Code inside an event structure is only allowed to run as long as a user is willing to look at a non-responsive program (eg. 20 ms)

Normally I try to keep the code under 100 ms.

Master-Slave is your friend.

Ton

[johnsold]

Doug,

As Ben and Ton also suggested a master/slave architecture is probably where you should be going.  At the very least some kind of state machine architecture will give you much more flexibility.

Without seeing your code it is hard to say whether any "easy" fix might work.

I suspect you are close to the point of choosing to spend some time learning how to  use one of these methods that we know will work or spending a lot of time tweaking and patching something which you might be able to get to work if the phase of the moon is favorable and you hold your mouth just right, until you need to change one little thing and then it won't work again.

Lynn 

[Doug_C]

You also have to lift your left foot off the ground, but your right Lynn, that's exactly where I am.  I've taught myself everything I know about labview over the past few months and I'm surprised how far its gotten me but I know I've only scratched the surface.  An "architecture" to a program is foreign to me. 

I used Ben's sugestion to wrtie the vi attached.  It would accomplish what I'm after, but its just another patch.

Thanks for the help, Problem Solved

Doug