Mouse Move Event interfering with Table Selection

[LLindenbauer]

Dear !ll!

I was experimenting with Tables and came upon this peculiar behaviour:

This happens when a new VI is created containing a table element and the "Mouse Move" event of the table element is registered by an event loop and the VI is run.

Under this condition, when trying to select multiple cells in the table, the selection mode stops after about 0.5 - 2 seconds. While holding down the mouse, further movements of the mouse do no longer change the size of the selected area. Sometimes, but not always, moving the mouse to the edge of the table and scrolling for a bit removes time limit and selections can be resized. It seems that the behaviour can be avoided by keeping the mouse still exactly at the critical time, e.g. it it is possible to move around wildly for about 300 milliseconds, stop moving the mouse for 2 seconds, then resume moving again. If there is no "Mouse Move" event deleted again, the behaviour stops.

When the selection mode stops, the GUI is still responsive as can be shown easily by wiring a display to the mouse coordinate terminal of the event structure.

I was able to reproduce this behaviour by creating a VI with just these components, using LabVIEW 16 (32 bit) on Win10 (64 bit).

I can't make sense of this - it seems that this has not been reported in the forums before. Right now it seems implementing functions that make use of selecting and mouse movement would either become a game of skill for the user. Is this corrected in later versions?

Best regards,

Leopold

[FireFist-Redhawk · Accepted solution]

Reproduced on LV'17 32 bit, Win10 64 bit. The behavior is arising from these settings though. Far be it from me to know what exactly is going on in the background, and maybe someone who knows way more about this than me can chime in here, but what I'm assuming is that the event queue for a control is lossy and so it can only handle so many events before some start getting bumped out of the queue by newer ones, and that is playing into it somehow.

The main thing though is that the default value of the settings outlined is to lock the front panel until the event case completes. Uncheck that box and the drag behavior returns to normal. Also, I haven't done anything really that needed to capture individual mouse move events, but I would imagine that having a limit on the number of those events would be advantageous from an overhead standpoint.

[Kyle97330 · Accepted solution]

I did a few experiments and found the following:

• It's confirmed for me too
• It happens in 2018 SP1 as well
• It doesn't matter if you register the event dynamically or limit the instances in the queue
• It also happens if you register a movement event on the entire pane instead of the Table control

However, I did find that if you go to the mouse move event, and uncheck the "Lock panel" option, the issue goes away.  So as long as having that unchecked works for you, there's a workaround.

[FireFist-Redhawk]

---

@Kyle97330 wrote:

• It doesn't matter if you register the event dynamically or limit the instances in the queue

Limiting the number of instances did fix it for me, as checking that box unchecks the box to Lock the FP (the two are mutually exclusive).

[LLindenbauer]

Thank both of You for confirming this and working out solutions! Both do work in LabVIEW 16 as well and I think I'll be able to use them.