Mouse wheel scrolling on hover
Moderators: Alexander Halser, Tim Green
Mouse wheel scrolling on hover
Long ago in my coding days I recall having to implement this. Right now, you have to click IN a topic in order to scroll the contents of that topic using the mouse wheel.
Ideally, I could click a topic in the Project Explorer, then just "hover" the mouse over the content and scroll it. It's a common behavior in apps. Essentially monitor mouse wheel notifications and note where the mouse is to handle the proper scroll.
Ideally, I could click a topic in the Project Explorer, then just "hover" the mouse over the content and scroll it. It's a common behavior in apps. Essentially monitor mouse wheel notifications and note where the mouse is to handle the proper scroll.
- Martin Wynne
- Posts: 2656
- Joined: Mon May 12, 2003 3:21 pm
- Location: West of the Severn, UK
Re: Mouse wheel scrolling on hover
Hi Ron,
This is a Windows setting on your system:
Works fine in HM8 if you undock the various panels.
cheers,
Martin.
This is a Windows setting on your system:
Works fine in HM8 if you undock the various panels.
cheers,
Martin.
You do not have the required permissions to view the files attached to this post.
- Darren Rose
- Posts: 204
- Joined: Sat Mar 03, 2012 3:01 pm
Re: Mouse wheel scrolling on hover
1) That setting is not relevant to the problem raised as it is enabled on mine anyway and I still have the issue
2) I also have the issue and have meant to post about it for ages now - it is a pain having to click in the topic before you can scroll up and down, and vice versa with TOC panel
2) I also have the issue and have meant to post about it for ages now - it is a pain having to click in the topic before you can scroll up and down, and vice versa with TOC panel
- Martin Wynne
- Posts: 2656
- Joined: Mon May 12, 2003 3:21 pm
- Location: West of the Severn, UK
Re: Mouse wheel scrolling on hover
Hi Darren,Darren Rose wrote: ↑Tue Apr 28, 2020 11:21 am 1) That setting is not relevant to the problem raised as it is enabled on mine anyway and I still have the issue
2) I also have the issue and have meant to post about it for ages now - it is a pain having to click in the topic before you can scroll up and down, and vice versa with TOC panel
Undock the TOC.
It all then works fine, in both HM8 and webhelp output. Scroll just by hovering.
Resize the main window, if you don't want the TOC on top of it. That also gives the full screen height available for the TOC:
cheers,
Martin.
Re: Mouse wheel scrolling on hover
That's a great suggestion, but not quite perfect. First, it's an annoyance that the TOC has to be undocked and resized every time I open the program; and second it seems I have to then click in the main window once before the scrolling moves with the mouse. But for a long session in H&M, it's definitely an improvement.
- Tim Green
- Site Admin
- Posts: 23183
- Joined: Mon Jun 24, 2002 9:11 am
- Location: Bruehl, Germany
- Contact:
Re: Mouse wheel scrolling on hover
Hi Tim,
Getting this activated for all the panes in Help+Manual also when they are docked is on the development wish list but it is apparently a lot more difficult to implement in Delphi than one might expect...
Getting this activated for all the panes in Help+Manual also when they are docked is on the development wish list but it is apparently a lot more difficult to implement in Delphi than one might expect...
Regards,
Tim (EC Software Documentation & User Support)
Private support:
Please do not email or PM me with private support requests -- post to the forum directly.
Tim (EC Software Documentation & User Support)
Private support:
Please do not email or PM me with private support requests -- post to the forum directly.
- Darren Rose
- Posts: 204
- Joined: Sat Mar 03, 2012 3:01 pm
Re: Mouse wheel scrolling on hover
@ Martin - thanks for that idea, had never tried with undocking
@ Tim - hopefully it will be fixed at some point, strange it is such an issue with Delphi though, as with any apps I program with C# and VB.NET it just works out of the box with most standard and 3rd party controls such as DevExpress etc
@ Tim - hopefully it will be fixed at some point, strange it is such an issue with Delphi though, as with any apps I program with C# and VB.NET it just works out of the box with most standard and 3rd party controls such as DevExpress etc
Re: Mouse wheel scrolling on hover
@Martin, thanks for that tip, but since the window arrangement is not remembered, it's not quite a daily-driver type of workaround. That option was already ON - by default I suppose - I just didn't know the un-dock idea. In an emergency if I'm having to review allot of chapters, the extra time to size/position might be worth the effort now that I know how to make it work
Also, like @Darren mentioned (and I found out before FULLY reading his post) you have to click in the main window once before the back and forth hover scrolling works.
It's also odd that any dockable pane controls these days don't offer the option to remember that layout. All I had at the time was Win32 so I just coded the functionality to remember allot of things like window/dialog/desktop metrics.
Also, like @Darren mentioned (and I found out before FULLY reading his post) you have to click in the main window once before the back and forth hover scrolling works.
It's also odd that any dockable pane controls these days don't offer the option to remember that layout. All I had at the time was Win32 so I just coded the functionality to remember allot of things like window/dialog/desktop metrics.
- Martin Wynne
- Posts: 2656
- Joined: Mon May 12, 2003 3:21 pm
- Location: West of the Severn, UK
Re: Mouse wheel scrolling on hover
Hi Ron,
I agree that it would be nice if HM8 remembered the docked state. But given that it does remember the size and position of the main window, it's only a couple of clicks to undock the TOC from it. How much extra time and effort do you need?
I'm always mystified by complaints such as these. I get the same with my own software. Someone is about to spend an hour or more using it, making hundreds of mouse clicks and key presses in the process, and complains bitterly about 2 extra clicks in the startup process. Spending a good half hour writing a long and detailed email telling me it's all wrong and I'm wasting their time.
I would much prefer the developers spend their time on actual functionality. Such as overwrite mode in the HM editor -- that would save me far more time than a couple of clicks at startup.
cheers,
Martin.
Re: Mouse wheel scrolling on hover
Hi Martin,
That's what I meant by 'worth the effort'. Your work around is noted and appreciated because if I were to spend even just 30 minutes working in the application, it's time well spent. It's just that I have to go through that process each time I start the app. But, an equally useful workaround for that I now realize is just to keep the app running/minimized. So I think that's what I'll do for now. I usually only have to restart twice/month.
The subject functionality - more and more common in many apps now - has become the expected behavior for me so I'm surprised when I don't experience it. If it was an oversight that can becorrected by an option in some control - maybe an easy fix. If not, I understand that as well. But expectation is the only reason I posted - I was surprised by the behavior.
Most often UI doesn't always equate to revenue and from a company perspective and I understand and have experienced that. There are often other changes that help more users than those complaining about a UI behavior. I can understand how delaying those features in favor of a less noticeable UI change would not make good business sense in some cases.
It's not that there's allot of time wasted getting the UI "set up" for optimum usability, it's just the extra effort - each time the app is started, however small it may be. I'm spoiled in that many (though not all) applications I use seem to all remember customized layouts made by the user. I don't know how many of those get that for free because of the components they use or how many actually have to take time to accommodate that behavior.
Say if automatic transmissions were somehow designed in a way that you had to shift into Drive and move forward every so slightly before you could shift to Reverse and back up. It's a small amount of effort and equally small amount of time needed. But it just seems wrong
That's what I meant by 'worth the effort'. Your work around is noted and appreciated because if I were to spend even just 30 minutes working in the application, it's time well spent. It's just that I have to go through that process each time I start the app. But, an equally useful workaround for that I now realize is just to keep the app running/minimized. So I think that's what I'll do for now. I usually only have to restart twice/month.
The subject functionality - more and more common in many apps now - has become the expected behavior for me so I'm surprised when I don't experience it. If it was an oversight that can becorrected by an option in some control - maybe an easy fix. If not, I understand that as well. But expectation is the only reason I posted - I was surprised by the behavior.
Most often UI doesn't always equate to revenue and from a company perspective and I understand and have experienced that. There are often other changes that help more users than those complaining about a UI behavior. I can understand how delaying those features in favor of a less noticeable UI change would not make good business sense in some cases.
It's not that there's allot of time wasted getting the UI "set up" for optimum usability, it's just the extra effort - each time the app is started, however small it may be. I'm spoiled in that many (though not all) applications I use seem to all remember customized layouts made by the user. I don't know how many of those get that for free because of the components they use or how many actually have to take time to accommodate that behavior.
Say if automatic transmissions were somehow designed in a way that you had to shift into Drive and move forward every so slightly before you could shift to Reverse and back up. It's a small amount of effort and equally small amount of time needed. But it just seems wrong
Re: Mouse wheel scrolling on hover
How would overwrite mode save time? I'm not a professional writer so maybe I have something to learn about here. Or maybe I've just been doing it all wrong since the beginning. I've pretty much never used overwrite mode in any application. Maybe it's just a style/method of writing. When I'm replacing text I usually highlight what I'm replacing and and delete it. Then type away. So in my case I do loose that time I had to take to delete the text I'm replacing.Martin Wynne wrote: ↑Wed Apr 29, 2020 6:14 am I would much prefer the developers spend their time on actual functionality. Such as overwrite mode in the HM editor -- that would save me far more time than a couple of clicks at startup.
- Martin Wynne
- Posts: 2656
- Joined: Mon May 12, 2003 3:21 pm
- Location: West of the Severn, UK
Re: Mouse wheel scrolling on hover
Hi Ron,
It's primarily for updating numeric data in tables. Usually having a fixed-width font.
In overwrite mode you just type in the new data without having to think about deleting the old. It's much easier to avoid mistakes with columns, decimal points and leading/trailing zeros if you can just type over the top of the old data to replace it.
Almost all other text editors and coding editors offer an overwrite mode. It's unfortunate that the RVF editor in H&M doesn't. Alexander did try to kludge an overwrite effect once, but it wasn't very usable.
cheers,
Martin.
Re: Mouse wheel scrolling on hover
Ah, indeed overwrite would be a nice addition for those situations and admittedly an even more basic functionality one might expect in an editor compared to say - scrolling a window that doesn't have focus