LabVIEW Idea Exchange

About LabVIEW Idea Exchange

Have a LabVIEW Idea?

  1. Browse by label or search in the LabVIEW Idea Exchange to see if your idea has previously been submitted. If your idea exists be sure to vote for the idea by giving it kudos to indicate your approval!
  2. If your idea has not been submitted click Post New Idea to submit a product idea to the LabVIEW Idea Exchange. Be sure to submit a separate post for each idea.
  3. Watch as the community gives your idea kudos and adds their input.
  4. As NI R&D considers the idea, they will change the idea status.
  5. Give kudos to other ideas that you would like to see in a future version of LabVIEW!
Showing results for 
Search instead for 
Did you mean: 

Give me a “modal when called” Front Panel / Window behavior or I will Kill LabVIEW (taskkill /f /im LabVIEW.exe)

Status: New

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).




JKI Blog

Is there ever a use for a VI being modal when not running? I think it could just be modal only when running period.

Active Participant

Hey @DerrickB.


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.

JKI Blog


Agree this is an issue. I always have a 'run when opened' VI on my desktop that finds all open model VIs and closes them. Saves killing LabVIEW. 


I was going to suggest under 'Show Front Panel when Loaded'

Is 'Close all model VIs on Run'

Idea being when you hit run - LabVIEW checks all other open windows for modal and closes them.

I figured this would be minimal overhead during run when LabVIEW is going through and reserving the VIs anyway. 

However it will also lose probes that you have set up on a modal BD. Your suggestion is probably better in this regard.  



Other forum refs:


Active Participant

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.


Chris Virgona
Proven Zealot

Here's my workaround:

Prevent Modal VIs Blocking.png


It has ups and downs:


- Find All Instances doesn't find the load and retained VI (bug?), so you'll have to add the VI in a disabled case if you want traceability.

- Code needed from each caller (could be wrapped in a VI of course).

+ Source code will behave the same as the executable.

Active Participant

That's a great work-around @wiebe!

JKI Blog
Knight of NI

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. 

"Should be" isn't "Is" -Jay
Active Participant Active Participant
Active Participant

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.

Screen Shot 2020-12-16 at 09.29.14.png


Close Some Modal Running VIs Snip.png



(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.

Proven Zealot

I'm pretty sure that VI doesn't close clones.


AKA How tiny things become huge problems in LabVIEW...




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.


Cannot attach, download here: