Acquire Input Data.vi does not reset Mouse Scrolling value in Windows 10

[pbuerki]

Hi,

We came across the following issue when we upgraded our systems from Windows 7 to Windows 10. We are still using LabVIEW 2011SP1 on Win10-64bit PCs. 

I isolated the issue in the attached VI Test Scroll Vertical Slider:

In Windows 7, the scrolling value resets to zero (0) after each scroll event, and the slider behaves as expected, i.e., it changes the value by 10 units for each scroll step.

In Windows 10, the scrolling value does not reset, and the slider keeps drifting indefinitely (or until it reaches the end of the scale). Even if I stop the VI and restart it, the Acquire Input Data.vi still remembers the previous value, and the slide control of the Test Scroll Vertical Slider.vi starts drifiting immediately after the restart.

Does somebody know a workaround for this issue? (Upgrading LabVIEW is not an option at this time.)

Thank you for your help.

[wiebe@CARYA]

Not sure how useful this is going to be...

LV11 is not supported on Windows 10: http://www.ni.com/product-documentation/53409/en/

On my Windows 10\LV18 it works just fine (I think).

On my Windows 10\LV13 (also not officially supported) it works just fine (I think).

You'd have to dig into that code, and see exactly what isn't behaving as expected. It can't be that hard to fix.

[pbuerki]

Hi wiebe,

Thank you for your reply. For the most part, our executables created with LV11 work fine on our Win 10 PCs. The described issue occurs consistently on our Win 10 PCs, e.g., Microsoft Windows 10 pro Version 10.0.16299 Build 16299.

The bug is occurring inside the LabVIEW lvinput.dll (Date modified 12/12/2011 4:47pm), so there is not much I can do to fix it. What is the latest version of this dll that is compatible with LV2011, and can somebody provide me with that newer compatible version?

Thank you in advance.

[MichaelBalzer]

Is using the Pane:Mouse Wheel event an option, or does it need to scroll regardless of window focus/mouse position?

[wiebe@CARYA]

Or if it's acceptable to keep the scroll bar (or a (off screen) dummy scrollbar) in focus, you could enable the build in mouse wheel action.

I'm not entirely sure if the event\mouse wheel action exist in LV11.

[wiebe@CARYA]

---

@pbuerki wrote:

The bug is occurring inside the LabVIEW lvinput.dll (Date modified 12/12/2011 4:47pm), so there is not much I can do to fix it. What is the latest version of this dll that is compatible with LV2011, and can somebody provide me with that newer compatible version?

---

The bug could also be in Windows. It's not the fist\only one.

[MichaelBalzer]

---

wiebe@CARYA wrote:

I'm not entirely sure if the event\mouse wheel action exist in LV11.

---

You're right, the LV2011 help for Pane Events doesn't mention it.

[wiebe@CARYA]

Upgrading LabVIEW is probably getting more and more attractive...

Why isn't this an option? Just the costs of purchase?

Of course it might not fix the problem. I'm not ruling out a Windows 10 problem.

[pbuerki]

Thank you all for your suggestions. Upgrading is not an option at this time, since we have a large application deployed on multiple systems across three continents. We do not have the resources right now to fix any potential bugs that might arise from the upgrade. Thus management has decided to wait with the upgrade for now.

I would like copy/pasting the lvinput.dll from a newer LabVIEW version (apparently the bug did not occur in LV2013) into my LabVIEW installation and try again. With a bit of luck, this would fix the problem for the time being.

[wiebe@CARYA]

I didn't see it in my LV13, but I haven't tried LV11 on my system (as it's not installed). It might not happen in LV11 in my system. This doesn't prove it's a LV11 problem.

Like I said, it could be Windows. You've mentioned it happens only in specific Window 10 builds. I doubt the lvinput.dll changed at lot, if at all.

Windows\MS does change mouse behavior if\when it feels like it. For instance recently the scrolling of the combo box list behavior changed.