Can I detect and handle an event while already inside an event structure?

[bracker]

I have a VI that would do what I want if I could detect and handle a second mouse-click event while I'm already handling a previous event (a shortcut menu selection).

I hope the image below is clear, but in words what I want is the following:  I first right click a graph and select a shortcut menu item, which specifies some manipulation of the graph properties.  Often, that manipulation requires clicking a second graph to obtain a reference (e.g. if I want to copy some properties of the first graph to the target graph).  Problem is, that means I'm trying to detect second event while already inside an event structure.

I suspect I could do this with a state machine and some shift registers, and if that's the simplest way, I will.  I'd be interested to know though, if there's a way to detect and handle "nested" events as I've suggested.

Thanks!

[altenbach]

---

bracker wrote:

I suspect I could do this with a state machine and some shift registers, and if that's the simplest way, I will. 

---

Yes, that's the right way. Go for it! 😄 It is simpler than you might think!

Feel free to attach your code in case you get stuck.

(Stay away from nested events, because event need to always be ready to react to events. They will queue up event even if they cannot execute due to dataflow problems. For example if the inner event detects a mouse-down, it will queue it up, but will not be able to service it untill the outer event occurs. Events are by default set to lock the front panel until the event completes, meaning the above scenario will get you into a deadlock situation. Event structures belong on the top diagram of a while loop, not inside case structures, not inside event structures, etc., ever!  And only one event structure per independent loop.)

[bracker]

I gave it a shot, and while it works, it is seems like a fair amount of overhead (three through-wires with SRs) for such a simple task.  Would you mind looking at "test graph property subroutines.vi" and tell me if there is a simpler way to do this?  If you want to run it, the other necessary files are included.  (I apologize if some of the actual graph routines misbehave, but that's a separate issue that I'm working on as well.

For one thing, I seem to have violated your previous advice:

"Event structures belong on the top diagram of a while loop, not inside case structures, not inside event structures, etc., ever!"

by using the event structure inside the "wait" case.  Isn't this ok for a user interface, where I'm just waiting for the user to do something anyway?   Should it be arranged as parallel loops (e.g. producer-consumer) even if it's only a user interface with a "wait" state?

I should mention, I've been using a SM/event user interface approach before without problems.  It works fine by itself, and when I need the user interface to work alongside a data collection loop, I put them in parallel, and the data collection loop talks to the user-interface SM through a user-defined event/event registration.

Thanks for your help.

[altenbach · Accepted solution]

Your code is not really that complicated. 😉

Still, the problem is that you tangle it up with the main state machine. I would use it in a small parallel loop that only handles events associated with menu shortcuts. All this should be able to execute in parallel anyway, even if the main loop updates the graph data at the same time, for example.

I don't like the dialog box, it impedes workflow, but if you use it, use a two button dialog so the user can also cancel if needed. Instead of the dialog, you chould just temporarily switch the cursor to something else. I would also do some sanity checking before operating on the second graph, and give a time limit for the second operation.

Here's a quick draft of a more atomic shortcut handler. Modify as needed. There are probably bugs.

[bracker]

Thanks!

[srikrishnaNF]

Hi altenbach,

  Can you post this code for LabVIEW 2009 version?

Thanks ,

srikrishnaNF

[bracker]

Here it is for 2009.