Wheel scrolling target incorrect

[Telcontar]

To reproduce, click any folder in the left tree panel.

Now hover the cursor over any other panel, and roll the mouse wheel. The right tree panel and either listing panel will scroll by one line and stop, and the left tree panel will scroll instead. The transcript panel won't scroll at all.

FlashFXP 3 introduced a modern behaviour where it would scroll whichever control is under the cursor, but this appears to have completely broken down. The status panel itself won't scroll with the wheel unless focused first.

I installed Tordex Wheel some time ago, which causes the window under the cursor to be scrolled with the wheel (the Mac/Linux behaviour), but FlashFXP is either designed in non-standard way, preventing Tordex Wheel or similar apps from correctly seeing each panel as a window, or it's intercepting wheel events strongly and stopping Tordex Wheel from solving the problem. Tordex Wheel for example works flawlessly in Explorer, where it will scroll whichever of the tree view or file area the cursor is over, likewise it handles FileZilla's various file and tree panels perfectly (since they refuse to support sensible scrolling in Windows even if Vista now changed the rules in favour of the modern Mac/Linux behaviour, which I did point out, and they won't listen).

In this case, the problem is still there without Tordex Wheel -- I quit it for a minute and still got exactly the same behaviour, so it's a internal conflict within FFXP between native and modern wheel scrolling where two windows are trying to accept the wheel events at once.

Tordex Wheel has absolutely no effect on FFXP, doesn't even let me scroll the status panel without focusing it.

[bigstar]

What mouse and OS do you have?

Using a MS IntelliMouse Explorer on XP 32bit/Vista 32bit/Windows 7 32/64bit the scrolling works as designed.

That is the control that the mouse cursor is hovering over is scrolled, not the focused control.

I installed Tordex Wheel to test and the scroll behavior is identical, nothing changes.

If any pane other than the one under the cursor is scrolled then I have to suspect the mouse driver causing it to scroll, because this is not the behavior of FlashFXP.

[Telcontar]

IntelliMouse Optical 1.1 in Win XP SP3 32-bit. I've seen this behaviour for a while, I just didn't spend time figuring out what it was doing as I had work to do. I've since installed IntelliPoint 8.0 together with the official IMO driver, and nothing has changed. Prior to that, I was using the stock HID USB mouse driver with XP.

Tordex Wheel doesn't cause the problem, but it should remedy it the way it does every other application. That it doesn't, indicates that FlashFXP itself is taking over the wheel events and handling them manually, making this an internal bug within the application. Also, Tordex Wheel should force the transcript pane to scroll when the cursor is over it, but you're explicitly blocking that from occurring.

[Edit: I assume you clicked a folder in the left panel first and left that control focused? That's what triggers it -- it causes that control to take the wheel focus events because it's focused even if FlashFXP is trying to scroll what's under the mouse at the same time. I am guessing it's some sort of Delphi built-in behaviour that's competing with FlashFXP's code.]

[bigstar]

I examined the delphi source code and I noticed a small issue with the logic of how mouse scrolling is handled. I found this page http://blogs.msdn.com/b/oldnewthing/.../07/54615.aspx that mentions the WHEEL_DELTA might have half a tick for high resolution mice.

Further testing revealed that I was able to reproduce this issue when the selected control has a horizontal scrollbar but not a vertical one.

Scrolling a full tick would scroll the control under the mouse cursor but a half tick would scroll the focused control.

The delphi VCL adds half ticks to a variable FWheelAccumulator for the control so that this can be combined with the next scroll tick, in the DoMouseWheel() function when a half tick comes in there is no condition to handle this case and the function returns false which then sends the scroll message to the parent control until all controls have been enumerated or one of them returns true.

We're trying to scroll a specific window and in my opinion a half tick should return true, instead of trying each parent control, since each control has its own FWheelAccumulator variable the half ticks add up and eventually trigger a scroll event that is equal to a full tick.

By changing this behavior in the Delphi VCL I was able to resolve the specific issue I noticed, I'm not entirely sure this is the exact issue you experienced, but I will send you a private message to a test build.

[Telcontar]

Today I get completely different behaviour to yesterday. The test build does clarify a little though.

What I see today, with the 4.0.0.1488 and the test build alike, is that if I click on any folder in the local tree panel (regardless of which side is local) -- the local tree panel takes ownership of wheel events and vetoes anything Tordex Wheel or FlashFXP wants to do instead (I've quit Tordex Wheel, no change with it closed).

With any folder focused in the local tree panel, the "[21:56:01] Scroll wheel up- Handled: true" events are not generated, so something within whatever class you're using has decided that it should handle scrolling by itself and it's not allowing anything whatsoever to override. I don't know whether Delphi fires events bottom up or top down, but again, Tordex Wheel should be able to intercept wheel events and direct them to the appropriate window (including panels) and it's not being allowed to.

Yesterday, though, I would find that if I selected either tree panel, the opposite one would scroll only one step in either direction while the selected one would scroll as normal. I don't see this at all now with the same build I was running yesterday, which is really frustrating.

Looks like there are various problems, but the test build has highlighted the problem with at least one of them!

[Telcontar]

Update: if I make both sides a local folder panel, and focus one, I can scroll either one with the wheel by hovering the cursor over it, yet no "Scroll wheel up- Handled: true" events are fired.

It's also possible in this scenario to roll the wheel over one of the two local tree panes and have its corresponding file pane scroll to match. No idea on debug messages as I'd gone back to build 1488 for a moment, and now I've gone back to your test build, it's stopped doing that.

Very definitely a bug with the tree panel class, but intermittent and constantly morphing.

(Tordex Wheel still not running.)