From Friday, April 19th (11:00 PM CDT) through Saturday, April 20th (2:00 PM CDT), 2024, ni.com will undergo system upgrades that may result in temporary service interruption.
We appreciate your patience as we improve our online experience.
We need a “modal when called” behavior where the VI is NOT modal when the VI is not currently running (being called). Otherwise, accidentally opening the VI during development while the main VI is running will make it so you can’t interact with any other front panels, block diagrams, or any other LabVIEW windows; and you’re stuck — you have to kill LabVIEW from task manager or cmd.exe (taskkill /f /im LabVIEW.exe)
My work-around is to add this little snippet of code that uses a Floating behavior in development and a Modal behavior in a built application (EXE).
Yes, there is a use case for a VI being modal when not "running" (actively executing code because it has been "called" by a parent). I draw this distinction, because a VI can have a state of Running when it's not actually executing (being called).
I've seen some clever use cases where a user interface VI does not have it's own While Loop, but is called by another VI (that does have a while loop). A good example of this might be something like a probe VI which only executes code when it gets new data, but its UI is open all the time.
Personally, I don't like these architectures, but it's a clever trick for showing the status of some low-level executing code without having to message the data up to the top level loop.
Kudos, because this is one of the most annoying behaviours of modal VIs during development. I would take pretty much any improvement over the existing behaviour.
However, the phrasing of the proposed option feels a bit cumbersome. I know what it means but it doesn't feel like the obvious choice somehow. I'd prefer if the default option was "Never modal during development" or something like that (as per Jim's snippet).
All that said, I'd happily settle for DerrickB's alternative: That VIs are never modal when not running. I'd forego all those wacky architectures to avoid having to occasionally having to kill my project.
Personally, I avoid saving vis as "Modal" all the vi FP options that make a vi model are run time writable! A simple vit with the FP properties set and unset, stuck in the Templates folder makes it fairly easy to use File>>New... (bonus, use a custom menu shotrcut, I set CTRL+~) that gives you a three click solution that is even easier than File>>VI Properties <Window options < select Dialog.. .and even has some starter vi documentation.
The down side is you have to manage your own setup when upgrading or starting with a new client's machine. VIPM pro can help you there! But, that's a cost add I have not yet been able to sell.
There is a VI the was passed around on Info-LabVIEW a long time ago, to "Close Some Running Modal VIs". It can be launched and as a modal VI is available when another modal VI is running. It lists all Modal VIs with open front panels and then allows the choice of which to kill. Used it for many many years.
(EDIT) And with a bit of Info-LabVIEW searching. I can credit it to Tim Streeter with Craig Graham hosting the code in 2004, but his original URL seems to be inoperative. But is available in the ancient Info-LabVIEW archive. http://info-labview.org/vi_library.html
In the meantime, to avoid killing LV and loose all the work not yet saved, I just kill the modal VI ('s) not all LV with a VI (auto-running) that I always keep on the desktop.