Is this on Windows? We updated the MouseWheel behavior to match the platform, so in other words, whatever control has the focus receives the MouseWheel event now (regardless of where the mouse pointer is located). As much as I don’t particularly like the Windows behavior it is what every other Windows app does. If no control has the focus then the Window (or ContainerControl) receives the MouseWheel event so you could code a workaround with that fact.
[quote=20927:@Ron Bower]Yes - On a windows platform.
This is a very significant loss of capability for my application and will take a lot of work to create a work-around.[/quote]
This code in the Control.MouseDown or Control.MouseEnter event should fix the problem:
Me.SetFocus does not allow response to Mousewheel when placed in a Windows 7 label.Mousedown or MouseEnter. I too have lost signficant capability with this change. I was scrolling the values of a plot minimum and maximum to adjust what was displayed. I had to change the labels to textfields to get it to work, at the cost of degraded appearance.
Oh that’s why the mousewheel doesn’t work in this clumsy new IDE in the same way as in the RS-IDE. Another reason to abandon Xojo/RS. In the RS-IDE while hovering over a listbox the listbox gets the mousewheel events, this was repaired in the RS-IDE and now in that unusable Xojo IDE it’s gone again while it is needed most.
The Ease of Access center under Windows 7 exposes some features (like focus follows mouse.) Other features are available through third party accessibility tools using the accessibility APIs. These APIs used have been present in Windows NT since (at least) NT 5.0.
OK I still do not see any such setting and I’ve been through every setting in the ease of access and the built in help.
There IS a setting for “Activate window by hovering over it with the mouse” but I don’t think thats quite the same thing.
I did google for focus follows mouse and all I could find were some registry hacks and some comments about this having some negative side effects.
AKA focus follows mouse, which is a documented feature of the operating system (Google SPI_SETACTIVEWINDOWTRACKING). The Windows 7 control panel feature also raises the focused window, but that’s an separate operation (see: SPI_SETACTIVEWNDTRKZORDER).
All I’m saying is that MouseWheel events should be raised whenever MW_MOUSEWHEEL messages are received by a control. They should propagate up the window hierarchy until the message is processed. Xojo should not be ignoring them based on internal state (e.g. AcceptFocus=False)
Let Windows determine which control has input focus and act accordingly.
[quote=34670:@Andrew L.]AKA focus follows mouse, which is a documented feature of the operating system (Google SPI_SETACTIVEWINDOWTRACKING). The Windows 7 control panel feature also raises the focused window, but that’s an separate operation (see: SPI_SETACTIVEWNDTRKZORDER).
Didn’t realize that this was the same thing you were talking about