Scrolling vs Back/Forward -- pane-dependent?

[PeterH]

Now just testing my next statement I found a bug??? Show a long .txt-file in preview and cursor over it scrolls just the preview (=OK for me!) *but* then move cursor over anything else (tree or list) scrolls that area, but *also* scrolls preview! (I.e. preview is always scrolled )

Indeed, over here the text preview scrolls one notch when you wheel-scroll any other element in the main window, but only if you scroll the text preview using the scroll bar at least one time. I'm afraid I have no influence over this. This scrolling is not mine but completely owned by Windows.

What's that? Today it doesn't work like yesterday? Different from what I remember, and different from what you describe
Now: if preview (of a .txt) is active, it (and nothing else) is scrolled - wherever the cursor is (even outside XY), but if tree or list is active preview is *not* scrolled, but only tree or list, if cursor is over it. I don't think that's nice - but at least acceptable!
(Yesterday I saw the preview scroll *together* with tree or list - this would be non-acceptable, I think.)
But why "yesterday so, today so"? (Modification of German saying "Heute so, morgen so." )

[zer0]

But you don't say anything to the point that mouse *must* be over tree to scroll tree, and over list to scroll list? That is: you *must* position the mouse to scroll what you want?

In respect of those, I would rather the active state dictate what is scrollable rather than a position of the cursor. For the tree, mine is locked at all times and is compact so little scrolling is required. In terms of the list's behaviour, I'd rather not it have mandatory to have to hover over something to scroll it. Being active is enough IMO