One window stalls while another window's menu is up

[CoastalMaineBird]

LV2013, Win7

I've never played much with VI Execution Systems and Priorities, but it looks like I may have to.

I have a window called MAIN, which has run time menus attached.

One of the menu items is OPEN MONITOR WINDOW, or if it's already open, that item is CLOSE MONITOR WINDOW.

The Monitor window is full-screen on a different monitor and has no menu bar of its own.

My customer has complained that if he chooses the CLOSE item too soon after choosing OPEN, then it doesn't close.

I have verified that.

The OPEN procedure opens a dynamically called VI for the Monitor Window.  

That Monitor VI opens 72 copies of a dynamically called VI to handle a block (a portion of the screen).  This normally takes 1500-2000 mSec.

If I do this sequence:

--- Choose OPEN MONITOR from the MAIN window's menu.

--- Click and hold open the MAIN window's menu for a while (say 10 seconds)

--- Choose CLOSE MONITOR from the MAIN window's menu.

Then the debugging logs show that when the MAIN window menu is activated, the MONITOR window starts up 1 or 2 more BLOCK VIs, and then stops opening them.  The ones that are already in the pipeline continue to start up and get ready, but no new ones get started.

Some of the blocks that are already running, do get data events, but other than that, NOTHING about the startup procedure runs while the menu is up.  The log is empty.

When the CLOSE MONITOR is chosen (the menu is withdrawn), the pipeline resumes again.  The MONITOR window resumes starting up all the blocks, and things seem normal from there on.

The CLOSE MONITOR event is ignored because the MONITOR window hasn't started its EVENT loop, because it was starting up the blocks.

So, why does the MONITOR startup procedure get stalled?  Is tracking the menu tying up the UI thread?

There's no extraordinary CPU usage while the MENU is up.

Should I raise the priority of the MONITOR window?  Should I put the "open 72 blocks" code into a separate execution system?

How do I analyze this ?  Trial and error is all I have now.

[tst]

---

CoastalMaineBird wrote:

So, why does the MONITOR startup procedure get stalled?  Is tracking the menu tying up the UI thread?

---

Not the UI thread, but the root loop, which apparently Open VI Reference also needs. I never dove into the details of this issue, but there are threads around which discuss it at some length and possibly also offer some workarounds (such as opening the reference beforehand).

[CoastalMaineBird]

OK, I never heard about the "root loop".  I found this thread which seems to corroborate your idea: http://forums.ni.com/t5/LabVIEW/droping-down-menu-pauses-program-at-open-ref/td-p/502803

That seems to fit my problem - thanks.

I found that lowering the priority of the MAIN VI to background, helps the problem as well.  That's not a good solution for me, as the menu (which I called MAIN MENU) actually appears in several other windows.  But it's a clue.

I'll chase the connection between OPEN REF and menus and root loopw first, though.

[CoastalMaineBird]

Well, I was already opening the thing  BY NAME.  That thread above showed that after he changed to BY NAME rather than BY PATH, the problem moved to the RUN VI call.

That seems to be what's happening here, too:

But it's already in a subVI, perhaps I can manipulate priorities there...

Or ... I vaguely remember something about a VI "pool"  Have to look that up...

[CoastalMaineBird]

Found an article about the ROOT LOOP.