Why the BUSY mouse cursor?

[CoastalMaineBird]

LV 2013SP1, Win7

I've got a situation where, when I choose a certain kind of menu item (from my program's menus), the mouse cursor switches to BUSY (the rolling blue tire).  It will stay that way until you actually move the mouse. Forever, it seems.

The CPU is NOT busy during this time, my CPU meter shows between 0 and 1 %.

I've been programming LabVIEW since 1990, and I've never used any mouse-cursor utilities.  So it's not some rogue code of mine.

When I select a certain thing from the menu, it causes me to use the menu tag as a file path (which refers to a packed Project Library), call the GET EXPORTED FILE PATH to get the path to a certain VI with that PPL, open up a reference to that VI, and execute it, then check for errors.

The VI that is executed is shown in the bottom part of this screen shot.

If I disable the part that runs the VI (as shown), then the busy cursor does NOT appear.

But that VI is extremely trivial and does nothing with the cursor.

My questions are:

What is telling the cursor to show "Busy"?

Why doesn't that entity turn it off?

Can I make it not happen?  It's misleading as heck.  

The time taken for all that sequence above is 90-120 mSec.  It's not like there is any justification for a BUSY signal.

[mikeporter]

Uhhhh, and what screenshot would all this be referencing?

Mike...

[CoastalMaineBird]

Why, this one, of course:

[mikeporter]

So you only see the issue if you leave the mouse perfectly still?

Well in terms of what turns the busy on, given what is happening in the code, it could be either LabVIEW or Windows doing it. Don't know why it wouldn't be turning off.

Another point is the it shouldn't matter how long it takes the VI being called to execute, how would it know how long it would take anyway?

Does it still happen if the path to the target VI doesn't come from a routine accessing a PPL or the target isn't in a PPL?

A strange thought. What if you put a delay in the target VI so it doesn't end right away? Still do it? Could be some sort of bizarre race condition.

Mike...

[Sam_Sharp]

Because you open the VI by path, it loads from disk (and as such runs in the root loop/UI thread) - perhaps it's the OS loading the file from disk is the reason why you get the busy cursor?

[CoastalMaineBird]

So you only see the issue if you leave the mouse perfectly still? 

Yes.   It's as if some logic somewhere is depending on me moving the mouse to update the cursor.  But I usually stop the mouse moving and release the button to choose an item.  So it's not like I'm doing some bizarre sequence.

Another point is the it shouldn't matter how long it takes the VI being called to execute, how would it know how long it would take anyway?

Well, some UI rules show the busy signal only after X seconds of being busy. If it ends before that, no need of signalling.  I thought something could be wrong with that, but at least that would clean itself up.  This busy signal will last forever if I don't move the mouse.

Does it still happen if the path to the target VI doesn't come from a routine accessing a PPL or the target isn't in a PPL?

I copied a target outside of a PPL and forced it to load from that location.  IOW, i still CHOOSE one within a PPL, and the GET PPL PATH still functions, then I substitute a different path.  

The VI loads and executes, but it DOES NOT indicate the BUSY signal.  So, you're on to something with that idea.

Somehow, loading the VI *-FROM A PPL-* triggers the busy signal.

 What if you put a delay in the target VI so it doesn't end right away? Still do it? Could be some sort of bizarre race condition.

I put a 2000 mSec WAIT in the target VI.  Now, when I choose this item, nothing happens until 2 sec AFTER I release the button.  THEN it turns busy, and stays until I move the mouse.  So it's something AFTER this open-run sequence.

[CoastalMaineBird]

Because you open the VI by path, it loads from disk (and as such runs in the root loop/UI thread) - perhaps it's the OS loading the file from disk is the reason why you get the busy cursor?

Well, if the OS turns it on, it's the OS's responsibility to turn it off.  It's only 100 mSec anyway.

I've done this operation lots of other times, but not from a menu.  Never saw this before.

If I force it to load from OTHER than the PPL, it des NOT show busy.

[CoastalMaineBird]

Here is the whole sequence.

PIC 1: I respond to a MENU SELECTION by handling the "standard" events first (switching windows, CutCopyPaste, etc).  If it's handled there, the result is blank, otherwise the tag is unchanged.

   If it's a "standard" event, none of this BUSY stuff happens.

  Otherwise, I check if it's from the ADDON menu by attempting to convert the menu tag into a path. If the path is NOT blank, it's an addon.  I display the path and trigger an UPDATE DESCRIPTION action.  I also switch tabs.  I've disabled that switch tabs, and nothing changes.

PIC 2: I take the selected path and update the UI from it.  (If there is an error, I use the error text and turn the text plain red, if no error, I use the text from the VI and show it in black italics).

  I can disable the CHECK AVAILABILITY action, and nothing changes.

PIC 3: shows details of the UI handling.

PIC 4: Here, given a PPL path, I obtain the path of a particular VI within it, open a ref at that path, execute that VI, and close the ref.  I check for errors and compose a message if so.  As I mentioned earlier, I can disable that execute sequence and this doesn't happen.

PIC 5:  The error checking does nothing if there is no error.

[CoastalMaineBird]

Now that I look at it, there's another place where it happens, as well.

When the window is first brought up, I do a scan and build the menu.

In this case, I clear out the submenu and list all folders in a certain folder.

For each one of those, I recurse and list all folders in that one, and so on.

Then I list all FILES (*.lvlibp) in the folder.

For each one, I get the path to a particular VI within the PPL and open and close (but do not execute) that VI.  

This is just to detect errors, like a missing VI or bad ConnPane, etc.

I then put the PPL name (with any error message) into the menu.

The idea is to build a menu structure that mirrors the disk folder structure, so they can organize these addons into catagories.

Whenever I do this, the mouse cursor turns busy, and stays that way until I move the mouse.

[mikeporter]

Given what you are finding, I think I would be tempted to try something like the attached (named for another coastal maine bird). Basically, load and buffer the file reference the first time its used. Let LabVIEW worry about closing it when the application stops.

Mike...