You said you have a queue that you put a shutdown command on from either action. I would just let both actions do the same thing. I don't see any benefit for consolidating further having one trigger the other.
If there were other things you have to do besides just putting the shutdown command on the queue, then wrap them all up in a Shutdown subVI and have both locations call that same subVI.
Yeh - I guess so, but have the same code twice? No matter how trivial? Just seems a shame you have VAL(Sig) for most controls but not other'menu' actions.
Sure. If code is trivial, then it is trivial to put it twice.
If the menu does something, whether it is one thing or a long list of things, and another action (like the X button) does something whether is is the same one thing or the same long list of things, at the bare minimum each one as to do one action.
It's like I can e-mail you to tell you to do something or text you to tell you to do something. Why would I need to send a text that triggers an e-mail to be sent? Or send an e-mail that triggers a text to be sent?
You think you are "simplifying" things by having two different actions do one thing, But really you are complicating it by having one action trigger the other action to do that one thing. That is still 2 steps.
If you think you'd use this event case somewhere else, you could have a "Stop" user event case that does your stopping. When your Panel Close? event fires, discard it and send a Stop user event. When your menu item gets chosen, send the same user event. This way you could theoretically add this functionality externally later on (if you use this code in a subVI), from the command line, etc.
I use the JKI State Machine for things like this.
Different events can fire off the same shutdown script (macro) from multiple places, you can even fire off that shutdown script with a user event also.
I would not put that logic inside the Event Case, put it outside(State Machine) so multiple events can access it.