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

[jlokanis]

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!

[AristosQueue (NI)]

You can make the existing Three Button Dialog.vi do what you want by passing empty strings for the labels of the buttons you don't want to display.

[jlokanis]

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?

[AristosQueue (NI)]

I wasn't arguing against your idea, just noting the workaround in the meantime. 🙂

[NathanDII]

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)

[AristosQueue (NI)]

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

[NathanDII]

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/picktime.vi

[Larry.C]

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

[AristosQueue (NI)]

This behavior remains unchanged in LV 2018.