Nested While Loop

[Qdsdh]

Hello,

Inside a while loop, I use an event structure, which in it's turn handles a little bit of program with another while loop. As long as I set the boolean true (the one that ends the while loop) before activating the event, the program runs. However, if i activate the event without setting the booleean true, the program does not respond anymore. If I use the same programming outside the event structure, it runs and responds to the boolean. Is this a memory problem of my pc or something or am i missing something?

In the events the while loop is being used under the noise measurement event.

Best of wishes

[pincpanter]

If you edit the affected event, you will see a checked checkbox: Lock panel until the event case completes.

This means that no user interaction is accepted during the event.

You may simply uncheck it, however beware that any further user interaction will be serviced when the event ends; for example, if you click Perform sweeps , this last function will be executed immediately after having stopped the inner while loop.

[dkfire]

Most likely you have configured the event with Lock Panel. 

Look at the settings for that event, and uncheck the Lock Panel. 

[crossrulz]

What you really should do is put the measuring in another loop.  You can use a queue to send it messages to start, stop, cose, etc.

[Qdsdh]

First of all, thank you everyone for your replies, it indeed was the lock panel setting. Why should I put the measuring in a different loop, for my understanding, what would the benefits be of doing this in comparisson to using an event structure? Obviously I am fairly new to labVIEW, but queue would be an term I can google and find what you mean ?

[GerdW]

Hi qdsdh,

what would the benefits be of doing this

First of all: an event structure should always react on events as soon as possible! (Did you read the LabVIEW help on event structures, especially the caveats?)

- That being said it is clear you should not put any loops (or other routines), that run for long time (longer than several milliseconds), inside an event.

- To handle events in parallel with other routines often a QMH (queued message handler) is used: that's what was suggested…

[wiebe@CARYA]

I personally don't mind timey stuff in an event structure. But the result is the UI is (should be) blocked. This sometimes is a feature\requirement, sometimes a noianse.

Blocking stuff in events can lead to problems, for instance if user events are fired and the event structure registered for them, you can't put a blocking dialog in one of the events. The user events will pile up until the applications runs out of memory (and switching to LV 64 bit is no solution). Mouse move events and such can also cause problems like that.

If blocking is undesired, some sort of parallel execution is required. It doesn't need to be a parallel loop. You can also dynamically start the process. The result (if required) can be passed by a callback control reference that is Value (signalling)-ed when done, a user event, and if it's no event but just data the usual tricks like (functional) globals. It reduces the need for a lot of glue code (enummed type defs, loop, case, queues, etc), but it's maybe a bit less transparent.

[Qdsdh]

Thanks for the info, the solution now works with a queued message handler. Really appreciate the help!