Capturing Scroll Wheel Events

[mje]

I can't seem to figure out how to capture scroll wheel events from a mouse. I have an X-Control that manually manages its v-scroll, and it seems counter-intuitive for the wheel not to work when hovering over top.

[Yair]

You can't capture the event (at least not with G code). You can use the input VIs to detect the scroll (one of the outputs should give a relative position of the wheel), but that would require you to poll it (and then you can create an event there). Since you're talking about an XControl, you would probably want to look at this -

There is an idea for this in the IE - http://forums.ni.com/t5/LabVIEW-Idea-Exchange/Add-a-quot-Mouse-Scroll-quot-event/idi-p/921547

[mje]

Thanks Yair. Interesting, I didn't recall that discussion. Definitely not ideal, mind you.

[hooovahh]

You absolutely can detect the event of a scroll wheel (at least in Windows). You use the Windows Message Queue to detect the scroll and fire a user event.

http://forums.ni.com/t5/LabVIEW/Mouse-wheel-scroll-event-ON-CHANGE/td-p/860112/page/2

Checkout the Scroll_Event_V2.zip file it has a nice example inside.

[mje]

Thanks, hooovahh. Using a hook ought to work, I was just hoping not to have to bust out the kernel calls. This would ultimately still require a worker task due to the xcontrol, although it would not be a polling, so that's good.

[hooovahh]

Yeah I totally agree that this should be a native LabVIEW function in the event structure. There are a few idea exchanges suggesting this, some with more votes than others. Here's the one I found with the most number (currently 229).

http://forums.ni.com...nt/idi-p/921547

EDIT: Currently this is the 16th most common kudo'ed idea.

http://forums.ni.com/t5/LabVIEW-Idea-Exchange/idb-p/labviewideas/status-key/new/tab/most-kudoed

[ShaunR]

Yeah I totally agree that this should be a native LabVIEW function in the event structure.

Event structures have been screaming to be re-vamped for years. Shame the focus so far (and for the foreseable future) is on less useful wizards and eye candy.

[mje]

Yeah I totally agree that this should be a native LabVIEW function in the event structure.

Indeed. The good news though is in normal UI situations (read: not an XControl) you can come pretty darned close. Make a user event, then pass it onto a DLL which registers the hook, meanwhile the LabVIEW side registers for the event dynamically with an event structure. When the DLL's hook callback gets called*, it forwards the signal into waiting LabVIEW event structures via a call to PostLVUserEvent.

Of course XControls don't play nice with dynamic events, so in that case you need the intermediate LabVIEW worker task. Seems the simplest option is to have a hidden control in the XControl, which you can then invoke a Val (Sgl) property change to affect statically linked code within the event structure (yes, that's creating a dynamic event and a worker task whose sole job is to ultimately trigger statically linked code). This is my first foray into XControls, and I'm still not convinced they are a good thing. Might be my last...

*There's of course a little more book keeping, such as comparing window handles and making sure the mouse coordinates are over the correct controls.

[MikaelH]

I would create a small spawning VI that polls the Scrolling info and then generate events.

Something like this:

ScrollWheel.zip

When I tried this on my computer I only got relative Scroll info from the LV VI, I know that some system only gives you relative and some absolute.

I'm not sure why but you have to support both.

Cheers,

Mike

[asbo]

When I tried this on my computer I only got relative Scroll info from the LV VI, I know that some system only gives you relative and some absolute.

I'm not sure why but you have to support both.

What implicates "have to"? Do some controls not report/respond to/whatever relative scrolling?

[MikaelH]

You will always get the Scrolling Event, but I've seen this VI being able to report an absolute value of the scrolling wheel on some computers.

Check the Process.VI and the timeout case where I query the Mouse info.

[davidz]

Hi Mike,

 

2 years later... In the meantime the Mouse Scroll Wheel Event is implemented in LV2013.

 

Unfortunately we have to implement all in LV2012 in our SW team, and have a similar solution implemented as yours. We have also implemented a way to deal with absolute scrolling wheel values, this to be on the safe side. But the thing is, that when calculating with absolute values, a system with relative scroll values doesn't work so fluid with that absolute logic, as e.g. when having a previous value -120 and next value is 120 then the result is 0 and nothing happens. We first thought, that absolute scroll behavior is occurring only on old systems, but now noticed, that when accessing a PC by remote desktop a mouse scroll value is always absolute.

 

In the code you of your ScrollWheel example you give back both scroll values, the absolute and the relative one. Did you also implement a logic to detect how the system behaves?