LabVIEW Idea Exchange

cancel
Showing results for 
Search instead for 
Did you mean: 
Mads

Run Method should not run in the user interface thread

Status: New

The Run Method is pretty much the only option we have in LabVIEW to scale an application dynamically by instantiating new VIs - but there is one big catch - for some reason it requires the unser interface to be idle(!).

 

Related methods like setting control values e.g. do not have this requirement so they do not pose a problem - but the main method for dynamic instantiation does - and can be blocked by something as simple as a user that opens the calendar view of a date and time control (which of course never should do this either, but that's another issue/idea).

 

Personally I use the run method to create new trend windows (you never know how many trends a user wants to see at the same time), create session handlers for remote clients etc. The times it is used to actually create user interfaces it is not a big problem that the run method is in the user interface thread, but for session handlers and other things that needs to be created in the background based on requests from the outside? A HUGE issue.

21 Comments
wiebe@CARYA
Knight of NI

This came up again here.

 

One of my least favorite 'escalation features' (where a simple requirement change or design choice requires a complete redesign, because things just don't work as expected).