Missing Mouse Up Bug

[Rusty Shackleford]

I have Labview 6.02. Sometimes when my VI is running, Labview misses
'mouse Button Up' events. So if I try to scroll, I can't let go of
the bar. Or a button will get stuck down. It usually catches the
'mouse Button up' about 5-10 seconds later. This make it really
difficult to use!

Anyone else seen this? Any solution?

-paul

[altenbach]

Curious, I don't remember seeing this. Could it be you are inadvertently "hammering" the CPU?

What is the VI priority setting? (If you e.g. force time-critical, unimportant things will get delayed). Leave it at "normal".

Is you code clean, with proper waits inserted or is it just spinning all loops as fast as it can?

What else is running on that PC? Is it communicating with DAQ hardware?

[Rusty Shackleford]

>What is the VI priority setting? (If you e.g. force time-critical,
>unimportant things will get delayed). Leave it at "normal".

I haven't changed any VI priority settings.

>Is you code clean, with proper waits inserted or is it just spinning
>all loops as fast as it can?

Many of the loops wait on ethernet data which comes only a few times
per second. But I'll see if I can delay some of the loops.

>What else is running on that PC? Is it communicating with DAQ
>hardware?

Nothing using any significant amount of CPU. No DAQ hardware. All
the communication is done over one ethernet connection.

-paul

[altenbach]

>Nothing is using any significant amount of CPU.

How is the actual CPU usage when the program is running?

I have written an application that sometimes receives spikes of up to 600 UDP packets/second (several ports). Its running on an old 133MHz Pentium and there is no slowdown at all.

How are you using the ethernet. UDP or TCP? For TCP, do you maintain a connection, or establish a new connection for each chunk of data? Do you use datasocket connections or plain TCP?

If using Windows, go to a command prompt and type "netstat -an" after runing the program for a while. Is there a buildup of many stale connections.

Of course it could also be a hardware conflict, e.g. between the drivers for the NIC and the video card. Have you upda
ted the network card drivers? Maybe try a different NIC or put it in a different PCI slot.

[Greg_McKaskle2]

> Nothing using any significant amount of CPU. No DAQ hardware. All
> the communication is done over one ethernet connection.
>


I think what is happening is that you are catching mouse move events.
At the moment, the event structure doesn't have a built-in mechanism for
collapsing mouse move events, and it will queue all of them the OS hands
it. If you do little or no processing for a move event, it isn't a
problem. If you spend much time, the queue gets pretty bug pretty fast,
then it takes your diagram multiple seconds to process them out of the
queue and find the mouse up.

If this sounds familiar, you can either process the move events faster,
put a limit on which ones you process using the timestamp or distance
comparis
on to the previous one processed, etc. You might even find some
devzone VIs that do this for you.

Greg McKaskle

[Rusty Shackleford]

There were a couple of places that I didn't have a delay in a loop. I
added a tiny delay to every loop and it cleared up. I didn't think
these loops would cause problems since they were only polling for a
switch.

Sorry if this was a really basic mistake, I'm still kind of new to
Labview.

-paul