Showing results for 
Search instead for 
Did you mean: 

Nonblocking dialog box



I've been having some trouble understanding a VI I found on the NI website. It is called 


I was wondering if there was any other simpler way to produce a non blocking dialog box?


Outputting a dialog box with a message is what I currently have, I would just like it to not stop my program from running. 










0 Kudos
Message 1 of 12

Hi Peter,


using the standard dialog boxes will always block your main VI.

So you have to make your own dialog window or to use that other VI... Where have you found it and what don't you "understand"?

Best regards,

using LV2016/2019/2021 on Win10/11+cRIO, TestStand2016/2019
0 Kudos
Message 2 of 12

A dialog box is just a subVI set to modal and requires user interaction to complete.


You could replace it with a subVI that is not modal, completes immediately, but does not close its FP after it is done executing. It could even force itself to the foreground whenever it is called.


For more details on panel options, check the relevant online help


Sometimes it is easier to just have a status indicator on the front panel of the main diagram that shows the message. It could change color depending of the severity of the message or even start blinking. Cluttering the computer screen with message dialog windows is tedious to the user. Imagine errors are piling up: he would need to constantly play whack-a-dialog instead of dealing with the real problem.

0 Kudos
Message 3 of 12

I assume you were talking about this example. (For clarity and proper credit, always provide a link!)


A dialog box can only be non blocking, if the downstream code does not care about the outcome (e.g. which button of a two button dialog was pressed). If there is data dependency, the code needs to wait (=blocking!) and there is no way around it.


PeterCh wrote:

I was wondering if there was any other simpler way to produce a non blocking dialog box?



Yes, the example above is way too elaborate for my taste!!!


If the dialog is supposed to be non-blocking and just display some message and does not care about user interactions ("OK buttons" and such), make it a subVI that does not contain any buttons, just the text display.


As hinted in my message above, make it complete immediately, but keep the panel open (i.e. no while loop or anything). It does not need to keep executing just to keep displaying the message! If you don't close the panel, it will remain forever and get updated with the new text if later called again. At the same time it will immedately hand over control to the calling program so it can continue (=non blocking!). It can always be dismissed with the big [X] in the upper right corner if it gets in the way and it will appear again the next time its called.


(make sure to only display the title bar, no scrollbar, menubar, toolbar, etc.)  


In summary, all this can be done with <<1% of the code of the quoted example!


All the code needs is a single string control assigned to an input terminal, nothing else!!! Make the control disabled (not grayed) so it acts like an indicator to the user and the text cannot be changed manually. Try it! 😄 

Message 4 of 12


 Hey Guys,



 I know it's been a while, but I haven't made any progress. I know this is frowned upon on this forum but I frankly don't know where else to turn to get this program to work without dedicating time to actually learning every little nuance of Labview. 


 I have this program and using your guys' suggestions I've tried to make an alarm message show up that is of the non-blocking variety. The reason for this is it is necessary to not have to stop the program to clear an error message. Well there is definitely something wrong with my use of Labview logic so I was hoping someone could tell me what exactly I'm doing wrong here. I either get a dialog box that pops up before there is even any sort of limit breach or I get no dialog box at all even when I get an alarm message. 


 The files are attached and any guidance is very much appreciated.



Download All
0 Kudos
Message 5 of 12

You still have your dialog box VI set up to block the exectution.  A while loop's iteration can't complete until your subVI completes.  And the subVI can't complete unti you've hit the stop button in it. 


Try this.


I put the Alert VI in a separate parallel loop and is triggered when it receives a notification.


I also cleaned up most of your Rube Goldberg code in the main VI.  And got rid of the greedy loop (while loop running infinitely fast polling the stop button) in your dialog VI.


There are some other ways to call the dialog VI, but I think you'll have some other problems if you try some of those.

Download All
0 Kudos
Message 6 of 12

To altenbach: The method used in the quoted example can be useful if you do need to take action based on the user's response, but don't want to hold up the main loop of the program while waiting for it. The consumer loop can return the user's response by setting a local variable that the main loop monitors. This technique can be used, for example, to display an error message that allows the user to abort the main loop, but with the main loop continuing to execute unless the user responds.

0 Kudos
Message 7 of 12

Let's ignore that you bumped a thread that hasn't had a post in 4 years to say that.


What application do you envision that lacks the ability to stop?  The suggested use you bring up makes sense if the main loop cannot be stopped elsewhere.  Instead, you're looking to make redundant places to stop the code.  This is in addition to making redundant ways to alert the user.  You're also looking to use local variables in a produce/consumer architecture instead of just enqueing the data.  Why? 

Message 8 of 12

The application that brought me here is a program that runs unattended for days at a time, monitoring a physical process that is being run by external hardware. In this case, it is not acceptable for the main loop to stop simply because an error has occurred, but I wanted to display a dialog showing the error message and giving the user the option of triggering a graceful shutdown of the system. In the event of an error, the process continues to run until the user checks on it, at which time the user can clear the error or abort the process.


In this case the only message the consumer loop needs to be able to send back to the producer loop is a binary "abort" signal. One could do that with queues or notifiers, but why would you?

0 Kudos
Message 9 of 12

@Laser_engineer wrote:
One could do that with queues or notifiers, but why would you?

I pose the same question to you.  In the event you need the program to continue running, you can flag a LED and display a warning in the primary UI.  This performs the same functionality as opening up a window to declare the error.  Both allow the program to keep running.  Both alert the user so the user can stop the program if desired when the user sees the warning.


One could do that with non-blocking dialog boxes, but why in the world would they add such unnecessary complexity that offers no gain?

0 Kudos
Message 10 of 12