mouse down in title bar momentarily freezes vi

[mattkav]

It appears that performing a mouse-down in the title bar temporarily hangs the UI thread for nearly half a second.  I have attached a vi that demostrates this issue.  Simply click and hold the mouse in the title bar and you will see gaps in the data.  If you move the mouse with the button pressed or let go of the button, then the freeze will release earlier.  We have also experienced this with a mouse down for other cases (e.g. scroll bars on String controls), but I was only able to easily recreate this on the title bar.

What is the explanation for this?  How do I get around it?

Is the problem similar to this thread?

http://forums.ni.com/ni/board/message?board.id=170&message.id=208255

I am using LabVIEW 8.5.1.

Thanks,
Matt K.

[johnsold]

Matt,

On my computer the effects are very subtle but visible.  Any mouse activity involves the OS and its communication with the application.  Clicking and holding in the title bar indicates to the OS that you may be about to move the window.  So the OS may hold up screen updates or delay giving control back to the app while it tries to decide what the user is going to do.

Other screen activity can produce a similar effect.  In the modified version of your VI which I attached delays will show up while the differences arrays are being updated. Also note that you get some different values of delays when the chart history fills up (at 1024 points) in your original VI.

Generally to avoid things like this you want to separate the data acquisition (the tick count in this case) from the user interface (GUI).  Also you want enough delay in the GUI loop that it only updates 10-20 times per second since the user cannot really see anything faster than that.   If you ran the tick count and the difference calculations in a separate loop and passed the displays to a slower parallel loop you could probably avoid most of these issues.

Lynn 

[mattkav]

Thanks Lynn.  Your modifications to my example really bring out other subtle effects.

How would you recommend to separate the DAQ from the GUI?  I assume one aspect is that I will need two separate vis with the DAQ vi marked to run in a different Execution System.  But how should I communicate the data between the two?  I have a few different ideas, but what is the best?  I am unsure of the best way to communicate between different Execution Systems such that the higher priority one isn't frozen by the UI.  Here are some thoughts.

1) Create a queue in the GUI thread and send all data from the DAQ to the GUI using the queue.  The GUI would store the history in this case.

2) Use TCP-IP messages to send all data from the DAQ to the GUI.  The GUI would store the history in this case.

3) Create a functional global variable that both the DAQ and GUI vis access.

4) Use a global variable.

Thanks again,

Matt K.

[johnsold]

Matt,

You have the right idea.  Queues and functional global variables (and Action Engines (AE), which may be thought of as functional globals on [legal] steroids) are usually the best way to move arrays of data between the independent loops.  Look at the Producer/Consumer design patterns which come with LV.  You do not need to do anything to run in different execution systems (unless you are on a real time system - I have no experience there).  LabVIEW's scheduler will create separate threads for independent loops automatically.  Put a small delay in each loop so one does not try to hog the CPU.  Even a 0 input to a Wait(ms) function will provide CPU resource sharing.

I have used both queues and Action Engines to pass data between loops.  If the data is only read at one place, the queue may be the simplest.  If the data needs to be read in multiple locations or other actions need to be performed, the AE may provide more versatility.  Search for Ben's Nugget on Action Engines.

Generally global variables are to be avoided for this kind of data transfer because of the possibility of race conditions.

Lynn