An event structure always queues up events, but if the event structure is not ready to execute (e.g. buried deep inside structures or dependent on something that has not completed), it will still lock the front panel until the event completes, and if it never can complete, you have a permanent deadlock.
LabVIEW is a graphical program and long paragraphs of ambiguous description are not useful to troubleshoot the problem. We cannot help you until you post some code. Seriously!!!!
The above shows one state inside the second event structure loop.
A picture is not code. Attach your VI! Where is the first event structure loop?
An event structure NEVER belong inside a case structure!!! Never ever!!!
None of your local variable are necessary, use shift registers instead!
All you need is ONE outer while loop and exactly ONE event structure total.
"The above shows one state inside the second event structure loop."
I should've said case, not state. (I still see it as a state, though. ...terminology.) It's showing one of the cases inside the loop. It's a case of an event structure inside a loop formed by the state machine.
...an event structure requires a loop, but no where does it say it must be a while loop. A loop is a loop. For instance, back in the day a classic loop was 10 print "hello": goto 10 ...that's an infinite loop of hellos.
I think a key piece of this puzzle is that crosshair pointer thing. Why did my arrowhead change to a crosshair?
I recommend the training resources listed at the top of the forum. This is getting way too silly.
As already said, an event structure does not belong inside a case structure. period. It seems like you have other event structure in other cases, a big no-no!
A while loop is correct for anything where the number of iterations is not known before the loop starts. Since you probably don't know how many events you will fire and how long the program will run, it is the only reasonable option. The cost of a while loop over a FOR loop is the need to check for the stop condition at each iteration.
If your cursor changed, you probably selected a specific tool from the tool palette. To go back to auto-select, hit the tab key, assuming you have auto-tools by default.
Again, if you want a quick learning path, attach your VI, tell us how it should be operated and what should happen and we will fix it using only 20% of your code size.
"All you need is ONE outer while loop and exactly ONE event structure total."
That doesn't seem reasonable, to me.
I do have one outer while loop, as it's running my state machine. However, an event structure must be in a loop, and it seems quite reasonable, to me, that out of, say, 10 states of a state machine, one or more states could hold event structures. For instance, as I'm selecting a string from my listbox, how would I move on after making my choice? Simple! I include an event for an "Accept" button change. Once my input from this first event structure loop's been had, then I move to the next state of the state machine, namely the state that does the math. Then I move to the state that plots the X(f). After this I move to "get input" and enter yet another event structure loop, my second such loop, which allows changing the graph of X(f); this state is "get input". But, once again, to leave I have a button to do it; otherwise, I'd be stuck in an infinite loop. This button is called "Stop", a giant button on my FP.
A way to look at this is imagine you have a row of boxes lined up running left to right. Now imagine a couple of the boxes have circular racetracks inside. The boxes are the states of the state machine. The racetracks are the event structure loops, sort of.
You seem to be saying I've broken some rule of LabVIEW in how I used an event structure.
I know my vi works wonderfully, to me, until I stick in that looksee at the mouse in that second event structure. When I do that I clobber all my FP controls and my arrowhead becomes a crosshair.
...it's so bizarre. I have to go do it again. I can change LabVIEW's mouse pointer!
I have another clue!
The change of the mouse pointer isn't consistent. It isn't a toggle. Sometimes my pointer remains an arrowhead. Other times it becomes a crosshair. In other words, each time I run the vi I do not get the same response, aside from clobbering my FP's controls -- that's consistent. (If it weren't I wouldn't be able to turn it on and off: Clobber functionality vs no-Clobber functionality.)
Then, when I take that mouse event out, all is well, again. In other words, I just revert and the clobber state is instantly gone. This is one puzzle! I sure wish someone could explain this to me.
Not that I'm not wanting the input of anyone out there who can explain why it happened, but I have a solution to the clobber problem.
In the event structure doc/help I found this:
|If no Event structure executes to handle an event and front panel locking is enabled, the user interface of the VI becomes unresponsive. If this occurs, click the Abort button to stop the VI. You can disable front panel locking by right-clicking the Event structure and removing the checkmark from the Lock front panel until the event case for this event completes checkbox in the Edit Events dialog box. You cannot turn off front panel locking for filter events.|
I unchecked the box and now the added event case at least can remain in existence to allow me to start building again.
That was weird! But the good news is it was not unknown, docs-wise.
Yep! Works like a champ! The x,y is changing quite smoothly with the mouse. I like it!