LabVIEW
VI runtime menu selection event broken in executable environment
Solved!
In my application, I set up a "MenuHandler" to provide a standard runtime menu for VIs that explicitly opt in. When I register a VI with the handler, I send the handler a message with the VI reference like this:
I then have event cases in the Menu handler for those "Menu Selection (User)" and "Menu Selection (App)" events:
In those event cases, I am generating log file entries for debugging purposes. Both the (User) and (App) events work as expected in the IDE, but when I build an executable, the (User) menu selection event case is not being triggered. Even more strangely, when I select a (User) menu item, not only does it not seem to execute that event case, but it also then renders that VI menu unresponsive (subsequent clicks on menu items are ignored, and there is a system *ding* sound indicating it is being blocked).
Has anyone encountered this, and are there any workarounds? Or can we just not register for (User) menu events in built executables? (This is using LabVIEW 2019).
Again, the behavior is exactly as expected/desired in the development environment (I actually have some user menu options that do things besides just debug logging). It only seems to break in the exe environment. The executable is definitely *registering* for the event, and it is doing *something* when the event occurs, but it isn't executing the code in that event case. It is acting like the event case structure is hanging somehow, but all the breadcrumbs I've tried to leave aren't helping me identify what is causing it to hang (no errors are thrown, and my manual log entries are not getting generated).
I see you have some kind of error handling in there. Is it possible to make the error come out in a text box, or use the Simple Error Handler VI to output the error message?
Edit oops you already tried that.
After more testing, I also noticed that the problematic behavior (VI menu locked out) was also happening in the IDE, but only the first time I ran my code. Subsequent runs would work nominally, but if I did a "close all" or fully quit LabVIEW, the next time I ran it, I would encounter that menu lockout nonsense.
That helped me finally find a workaround: I had to explicitly obtain a reference to the VI's menu bar, before passing responsibility of handling menu events off to another VI.
Originally, I was only handing a VI Reference to the "MenuHandler" VI (a single "actor" like VI that would apply a standard menu and handle the menu selection events from multiple VIs). The MenuHandler would set the VI runtime menu path (loading a default *.rtm file) and then register for the Menu Selection events. Both of those actions -- setting the runtime menu path and registering for menu events -- are done using only a VI reference, and do not require the use of the VI's menu reference.
Once I dropped in the "Current VI's Menubar" primitive (didn't even do anything with it; literally just dropped that function down on the BD), the menu events started working consistently, even in the executable.
So my guess is that somehow LabVIEW is "optimizing" things behind the scenes by assuming we aren't going to need to worry about the menu if we haven't explicitly referenced it. I have seen similar things where VI front panels are stripped out at build time unless you explicitly reference something on the panel (I would just drop a static reference to a control on the front panel for any VI that I might want to dynamically open within an exe).
It's still super frustrating that there were no errors thrown at even registration time. And even weirder that the application menu items (like show/hide context help) worked consistently, but the user menu selections were breaking. I lost a couple hours digging into this, so if anyone from NI is following, it might be worth filing a CAR.
