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: 

Make it possible to dispatch VIs dynamically when the UI thread is blocked (or introduce multiple UI threads)

Many LabVIEW functions use the UI thread, like DataSocket (due to ActiveX events IIRC), everything VI Server etc., and since there is only one UI thread (per LV instance, no matter the number of logical processors, right? Also on Real-Time?) these functions are blocked when the UI thread is occupied by something else.


What I find particularly troubling is the fact that you can't dispatch VIs dynamically when the UI thread is blocked - for instance if a dialog is open or a user is selecting something in the menu. The latter can be an application blocker, if you are dispatching 20 VIs to populate your UI for example, and the user clicks the menu bar (without selecting something), your app might freeze since you won't be able to dispatch anymore VIs until the user lets go of the menu bar. There are many much simpler scenarios that you'll hit more often (a DataSocket read with a long timeout may block your dynamic VI from loading?).


Upping the count of UI threads from one to several would be great, but probably out of the question due to the implications to the LabVIEW core.


Instead, could we at least get the 'Open VI Reference' function and the 'Run VI' VI Server method freed from the UI thread? That would enable dynamic dispatching while the UI thread is blocked. Other VI Server calls aren't that important to get out of the UI thread, since there are other (and better) ways to transfer data to your dynamic VI for instance, than with VI Server. One curious thing is that it's possible to open all the 'One Button Dialogs' you want in parallel for instance - I'd think they'd run in the UI thread, and hence the first one'd block the rest?


A (somewhat contrived) example that fails due to this limitation:



The blue statement is true even when DynVI doesn't touch the UI thread, and even when no VI in the hierarchy runs in the UI thread etc. It's simply the 'Open VI Reference' primitive and the invoke node that gets blocked, due to the one button dialog being open.




CLA, CTA, CLED & LabVIEW Champion
Active Participant
Active Participant

Thanks, this is a duplicate then, and I understand the issues involved from the earlier post(s) you link to.




CLA, CTA, CLED & LabVIEW Champion
NI Employee (retired)