I have an application that was developed under Real Studio. I have converted it and compiled it under Xojo 2013r1.
I have a window with several TextFields on a data entry form. One of those text fields allows a user to enter data directly, or just use the mouse wheel to scroll a value up/down by a set amount.
The application works well under Xojo 2013r1, However, using Xojo 2013r2, the MouseWheel Event does not fire UNLESS the user first clicks on the TextField to give it focus.
Has anyone else noticed this problem in X0jo 2013r2 ?
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.
I’m seeing this behavior on Windows 7/2013r3, and using Spy++ confirmed that the “RB_CanvasPane” (it was a Canvas control) is receiving the WM_MOUSEWHEEL messages.
FIX 23050 Windows: MouseWheel events are now received for controls that have the focus, regardless of where the mouse cursor is. This matches the default behavior on Windows.
Which setting ?
I poked about in my Windows 7 VM and can find all kinds of settings but not one that allows the non-focused control to get mouse scroll events.
Maybe I missed something ?
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).
[/quote]
Didn’t realize that this was the same thing you were talking about
