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: 

Change one and two button dialog windows do they do not block the root loop

Status: New

Currently, if you use the stock one and two button dialog VIs in your code, they will block the root loop while being displayed.

For those of you who don't know what the 'root loop' is, this is the core process of LabVIEW that many UI functions must execute under.  One of the key functions that executes in the root loop is VI Server calls to open a new dynamic VI.  So, if your code has multiple threads all performing operations that involve dynamic calls to other 'plug-in' VIs and one part of your code calls one of these stock dialog VIs, then all the other threads will be blocked until the user clears the dialog.

As a result of this, I have had to write my own 'root loop safe' versions of these dialogs to prevent this from happening.


As a side note, dropping down a menu and leaving it down without selecting anything also blocks the root loop.  It would be great if they could fix this too!



Certified LabVIEW Architect
Proven Zealot
You can make the existing Three Button do what you want by passing empty strings for the labels of the buttons you don't want to display.
Active Participant

That is basically what I did, plus I added some code to have the dialog find the first open parent calling it and center it's window on that FP.

But my 'idea' is this is not intuitive to the normal user and they could run into this problem and be very confused as to why this is happening.  It is not an easy to debug side effect.  And since it can be worked around in code, why not incorporate that work around into the shipping version of LabVIEW?

Certified LabVIEW Architect
Proven Zealot
I wasn't arguing against your idea, just noting the workaround in the meantime. 🙂

I'm not really sure how this isn't a bug.  It happens with the time stamp dialog too.


Has this been updated in any version of LabVIEW yet?


Drop down menus don't seem to affect anything (LV2009)

Proven Zealot

NathanDll: No. No change has been made in this area.


For anyone having the issue with the time/data picker dialog, this post was extremely helpful.  Basically, it says that there exists an equivalent dialog in the LabVIEW installation located at <LabVIEW XXXX>/resource/dialog/

Active Participant

I have now been bitten by the "Root Loop Bug" which has resulted in consequences in our standard architecture. We use a lot of asynchronously called "services" which handle things like broadcasting rig settings and dealing with plug-in operations. These get stalled whenever anyone interacts with any menu system in LabVIEW including the enum, combo box, VI menu, dialogs, modal windows, etc...


As we have critical "services" that are running we have implemented a watchdog which monitors their behaviour. By interrupting the "services" for UI interaction the watchdog will often shutdown the rig as it thinks there is something wrong (which there is » service is unresponsive).


I need to be able to make asynch calls at times when the UI is busy. I can't believe this is not a major discussed issue in LabVIEW.


Has this been updated and fixed since 2015? That is where this discussion has seemed to end.


Kind Regards,



Larry Colvin
Associate Principal Engineer
Dyson Technology Ltd.

Proven Zealot

This behavior remains unchanged in LV 2018.