Cannot Instanciate New VI when the Root Loop Hangs

[Jim Kring]

I didn't write LabVIEW and I don't know exactly how the guts of it works, but it appears that the Root Loop (a synchronous task handling loop at the very core of LabVIEW) hangs when the pull-down (or Run-Time) menu is in-use, a pop-up menu is in-use, or a dialog (such as the error dialog, file dialog, etc) is open.

By "Instantiate New VIs", I mean:

• Open a VI Reference to a VI on disk that is not already in memory
  
• Open a VI Reference to a reentrant VI, thus creating a new instance
  
• Open a VI Reference to a VI Template on disk, thus creating a new instance
  

The implication of this fact is that one cannot:

• Spawn a process using either the VI Template or Reentrant VI approach
  
• Instantiate Instances of OpenGOOP objects (which use a reentrant VI instance as the data store)
  

This is too, bad since spawning VIs is a very powerful technique. Is this a problem/bug for the majority of the power-users out there? IMO, process spawning and GOOP are very important design patterns that my applications cannot live without.

Is there something that I missed and is it possible to get around this issue?

[jpdrolet]

I didn't write LabVIEW and I don't know exactly how the guts of it works, but it appears that the Root Loop (a synchronous task handling loop at the very core of LabVIEW) hangs when the pull-down (or Run-Time) menu is in-use, a pop-up menu is in-use, or a dialog (such as the error dialog, file dialog, etc) is open.

By "Instantiate New VIs", I mean:

• Open a VI Reference to a VI on disk that is not already in memory
  
• Open a VI Reference to a reentrant VI, thus creating a new instance
  
• Open a VI Reference to a VI Template on disk, thus creating a new instance
  

The implication of this fact is that one cannot:

• Spawn a process using either the VI Template or Reentrant VI approach
  
• Instantiate Instances of OpenGOOP objects (which use a reentrant VI instance as the data store)
  

This is too, bad since spawning VIs is a very powerful technique.  Is this a problem/bug for the majority of the power-users out there?  IMO, process spawning and GOOP are very important design patterns that my applications cannot live without.

Is there something that I missed and is it possible to get around this issue?

1539[/snapback]

I've noticed that long ago. Open VI Reference is blocked by modal windows maybe because it runs in the UI thread. I think you can add a modal VI to that list.

It is very annoying. The only workaround I see is to create these VIs in a separate instance of LabVIEW/Run-Time App. Or maybe having one application space reseved exclusively for user interface while another does the background stuff.

* surfs searchview.net *

Hum. THAT long ago?

http://messages.info-labview.org/2000/03/10/28.html

[Mike Ashe]

It is very annoying.  The only workaround I see is to create these VIs in a separate instance of LabVIEW/Run-Time App. Or maybe having one application space reseved exclusively for user interface while another does the background stuff.

1541[/snapback]

Almost like having a LabVIEW Service that is invisible and a Monitor/UI (in System Tray or not) that is the only part we "see". This is the method I am implementing at the moment on a project that spawns communication handlers. I had observed that occasionally the spawning would hang. Not good in a distributed Client-Server architecture.

Mike

[Jim Kring]

Almost like having a LabVIEW Service that is invisible and a Monitor/UI (in System Tray or not) that is the only part we "see".  This is the method I am implementing at the moment on a project that spawns communication handlers. I had observed that occasionally the spawning would hang. Not good in a distributed Client-Server architecture.

Mike

1932[/snapback]

This is exactly the problem that I am having. I am spawning communication handers and my application stops communicating when the root loop hangs -- For example: when the General Error Handler (or other dialog) is open. Talk about annoying!