I just noticed that in Delphi 10.1 when I use the mouse wheel while the mouse cursor is over the project manager it still scrolls in the source editor (which has the focus) and not in the project manager (or any other control the mouse cursor is over) - when I do the same in Delphi 10 it works (Windows 8.1).
I just noticed that in Delphi 10.1 when I use the mouse wheel while the mouse cursor is over the project manager it still scrolls in the source editor (which has the focus) and not in the project manager (or any other control the mouse cursor is over) - when I do the same in Delphi 10 it works (Windows 8.1).
Can anyone reproduce this?
Edit: reported as https://quality.embarcadero.com/browse/RSP-15291
Can anyone reproduce this?
Edit: reported as https://quality.embarcadero.com/browse/RSP-15291
(10.1/Win 8.1) It the depends on the focus for me. If I click in the editor, the editor will scroll, regardless where the mouse cursor is. If I've clicked in the project manager, the PM will scroll, even if mouse cursor is hovering above the text editor.
ReplyDeleteLars Fosdal Yes, which is the wrong behavior imo.
ReplyDeleteIt works for me. I mean it works as Stefan Glienke describes it should. Editor has focus, can type in the editor, mouse wheel over other pane and THAT ONE scrolls.
ReplyDeleteWindows 10 and RAD 10.1 Berlin.
Stefan Glienke XE5 in XP vm behaves the way you expect.....
ReplyDeleteI think that third party drivers may be an issue here, and certainly add-ins would be. At least for the sake of testing, it would be best to be sure that only the Windows native mouse driver is in play.
ReplyDeleteBill Meyer And how is that relevant if on the same machine in 10.0 it works and on 10.1 it does not if I may ask?
ReplyDeleteStefan Glienke Clearly, for you it is not. But when getting responses from others, it may be. Or at least, if someone does not have the same experience with the same releases, and has a third party driver in place, it is a reasonable question to ask.
ReplyDeleteBill Meyer True that. So far it seems that Lars and me can reproduce this on the same Windows version (8.1) while Marco on 10 cannot.
ReplyDeleteStefan Glienke
ReplyDeleteAnd that was the point I was trying to make. When you start polling the experience of others, some of them may not see what you do, as their mouse driver -- or add-in -- interposes other behaviors.
I can confirm that behaviour, at least on Win7 - in Delphi 10.1 Berlin the project manager does not scroll when the code editor has the focus, in Delphi 10 Seattle it does scroll.
ReplyDeleteStarting with Windows 10, Microsoft added a setting "Inaktive Fenster beim Draufzeigen scrollen" (Scroll inactive windows on hover). You can try this for example in File Explorer (Windows Explorer): Move the pointer over the tree and scroll, move the pointer over the file list and scroll. In older Windows versions, you have to click first into the tree or the list to make them respond to the scrolling wheel.
ReplyDeleteOn my Windows 10 system, this setting is activated, and both Delphi 10 Seattle and Berlin behave like I expect it: It scrolls the tree/list/code where the mouse pointer is hovering.
There are several tools to get this behaviour in older windows version, i.e. "Flashwheel":
https://sourceforge.net/projects/flashwheel/files/flashwheel/1.0/flashwheel-VistaFix.exe/download
HTH,
Achim
Achim Kalwa The issue is not inactive windows. That would be when I have Chrome focused and move the mouse to my Delphi IDE and scroll the mouse wheel (nothing happens on my Windows 8.1).
ReplyDeleteIt could be though that this feature is making Berlin work on Windows 10 and hiding the issue.
Stefan Glienke You are right. When disabling this mouse setting in Windows 10, D10 Seattle scrolls the project list, while Berlin does not. I have to click into the project manager to make it scroll. So I can confirm this is a bug in D10 Berlin.
ReplyDeleteA related issue is that in XE7, with the form designer holding focus, the mouse wheel scrolls the Object Inspector. This remains true whether or not the form designer can display the full form height. (Windows 7)
ReplyDeleteBerlin on Windows 7 behaves as Stefan describes in his OP. Seattle on Windows 10 behaves as he suggests it should as well - no need to focus a panel to get it to scroll with the mouse wheel. XE on XP behaves that way as well.
ReplyDeleteMy answer is yes, I can reproduce this.
Stefan Glienke I thought I maybe able to give some inputs to tracking this down, as this was a pet topic for me some years ago and I even covered it in a CodeRage session (this part starts at 9:55):
ReplyDeletehttps://youtu.be/Jq1B-zjSBlA?list=PLsgBk6oyTnQJBB2cvqLDjLV5IqVGBFA4w&t=595
Some info as per my observation and reading (you'll know a lot of this, but for others reading...):
- The default behaviour of Windows has been to send the mouse wheel messages to the window that has focus - window meaning the control.
- The save behaviour followed into .NET as it was based on Windows SDK and it was not overridden.
- VCL, since it wraps Windows SDK by default also behaves this way.
- Java (Swing, etc.) implements the mouse wheel behaviour the right way. You don't have to do anything special in your app/control.
- Linux - I'm not 100% sure, but from what I remember, by default, has the right behaviour.
- Most of the popular Microsoft apps (Office, etc.) do that special thing to get the mouse wheel to behave the way it should - the non-irritating way ;) where you don't have to click on a control/window to scroll using the wheel.
- Delphi also has this mouse wheel hook code (something like the one shown in the video above) somewhere in the IDE code to make the wheel work the way we want it to. We use this code also in our UI components, but we don't put the init in the initialization section anymore.
Now maybe this code was left out/changed in Berlin because Windows 10 now has this option to make the mouse wheel work the right way and Berlin wants to let the user choose? If that was indeed done, maybe it should check the version of the OS it's running on?
You should be able to fix this temporarily (before an official fix) by putting code similar to the one in the video in a new package and loading it when the IDE starts.
Girish Patil Thanks for your detailed explanation - I just tried it with a designtime package inside 10.1 but it did not work. (DoMouseWheel of the controls that stopped working always returns false - but it does also in 10.0 so I guess that is not the way to fix it)
ReplyDeletePossibly related: It seems that the mouse wheel in 10.1 Berlin no longer scrolls the editor tabs left/right as it did in 10 Seattle.
ReplyDeleteStefan Glienke I was thinking when I wrote... will only a designtime package will be enough. I don't have Berlin on my current system. I'll check this later today and see if I can have something.
ReplyDeleteGirish Patil My first guess is that the controls somehow must have lost their mousewheel event handlers in Berlin. Because just adding a mouse hook does not turn on anything without the controls handling OnMouseWheel or OnMouseWheelDown/Up right?
ReplyDeleteStefan Glienke Right the OnMouseWheel event handlers are required. Since the wheel works on the control when you focus the control, they should be in place.
ReplyDeleteGirish Patil Oh yes, that is true. I just wonder why it does not work. I quickly debugged and its calling the DoMouseWheel method on the proper controls (where the mouse is over) but they don't do anything.
ReplyDeleteThis is the unit I put into a designtime package which I installed: http://pastebin.com/zVns1ruA
Lars Fosdal Hey that's cool! I can confirm that that feature does not work in XE.
ReplyDelete