Using Mouse Wheel for Scrolling down a long Form (1 Viewer)
- Thread starter ions
- Start date
missinglinq
AWF VIP
- Local time
- Today, 15:27
- Joined
- Jun 20, 2003
- Messages
- 6,423
I've seen this question posed literally dozens of times, here and on half a dozen other Access forums, and have never seen a working solution.
And most experienced developers will tell you that you should never have a Single View Form so long that it requires scrolling! This is one of the least user-friendly things you can possibly do. If you have a 'real-estate' problem causing this you need to consider using a tabbed page control.
And most experienced developers will tell you that you should never have a Single View Form so long that it requires scrolling! This is one of the least user-friendly things you can possibly do. If you have a 'real-estate' problem causing this you need to consider using a tabbed page control.
While I do agree with missinglinq, you shouldn't have such huge form that it requires scrolling, it is possible to enable scrolling by doing this:
1) Maximize the form. This solves the problem of two scrollbars, one for Access Windows and one for the form itself.
2) Use MouseOver event for all non-interactive controls & form's section to set focus back to a control contained on the form's header section. A good candidate is a textbox that's locked, enabled, has height & width of zero twips (e.g. practically invisible but without disable the .Visible property)
It should then work. Mostly. There are some gotchas, and I'm going to bet that it'd be next to useless if the forms had several interactive controls which would certainly conflict with the Setfocus behavior.
Believe me, it's easier to just use a tab control or subform to "page" the whole thing.
1) Maximize the form. This solves the problem of two scrollbars, one for Access Windows and one for the form itself.
2) Use MouseOver event for all non-interactive controls & form's section to set focus back to a control contained on the form's header section. A good candidate is a textbox that's locked, enabled, has height & width of zero twips (e.g. practically invisible but without disable the .Visible property)
It should then work. Mostly. There are some gotchas, and I'm going to bet that it'd be next to useless if the forms had several interactive controls which would certainly conflict with the Setfocus behavior.
Believe me, it's easier to just use a tab control or subform to "page" the whole thing.
driver7408
Registered User.
- Local time
- Today, 12:27
- Joined
- Feb 7, 2010
- Messages
- 72
Not to resurrect an old thread, but I came across this issue as well and could not find a solution anywhere online, yet a handful of people have been looking for answers.
Yes, some forms should not be so long to be scrolled to begin with, but certain design implications may dictate doing so. In my case the form is much more readable by scrolling than it would be to split it up.
My issue was whenever I clicked in a subform, I lost the scroll ability in the main form. What I did to remedy this was on that subform's "on Mouse Wheel" event, I added a vba command to set the focus to a control on the main form (I referenced a button on the mainform)
This solved the problem for me and now I have scroll ability on the entire form at all times. I hope this helps anyone else with this issue.
Yes, some forms should not be so long to be scrolled to begin with, but certain design implications may dictate doing so. In my case the form is much more readable by scrolling than it would be to split it up.
My issue was whenever I clicked in a subform, I lost the scroll ability in the main form. What I did to remedy this was on that subform's "on Mouse Wheel" event, I added a vba command to set the focus to a control on the main form (I referenced a button on the mainform)
This solved the problem for me and now I have scroll ability on the entire form at all times. I hope this helps anyone else with this issue.
