When the mouse wheel is used to change the position of a TScrollBar, what determines the size of the increment?

Empirically it appears to be related to the PageSize property but not in an obvious way.

It's clear from TCustomScrollBar.DoScroll that it's unrelated to LargeChange and SmallChange.

Can the resolution of this increment be set independently of PageSize?

Thx, Bruce.

PS: I'm using Debian Lenny with LCL/GTK2 from the latest SVN.

Some time ago I've used a dual definition for the mouse wheel scroll: positive values indicate an item count (items=lines...), and negative values mean fractions of the page (window) size, e.g. -3 means 1/3 page. Such a convention could e.g. replace and extend the SynEdit half-page scroll option.

DoDi

I would much rather like to see the dynamic scrolling support as can be seen in Mac OS X. Scroll the mouse slowly and content only scrolls a few pixels or lines. Scroll the mouse fast and the content scrolls my much larger amounts. I'm not a Mac OS X user, but I think that behaviour is fantastic.

I think all widgetsets could do with that behaviour as well.

Regards,
- Graeme -

________________________________________________
fpGUI - a cross-platform Free Pascal GUI toolkit
http://opensoft.homeip.net/fpgui/

Under windows you can set the amount of lines, in the windows control center.
The Windows-Widgetsets, passes this information on to the individual components (except, it only picks up changes, if Lazarus is restarted).

Martin

Martin Friebe wrote

Under windows you can set the amount of lines, in the windows control center.

Thanks not how it works in Mac OS X. Windows and Linux works my detecting the mousewheel delta and move a set about of lines. eg: 1, 3, 5 lines etc... Mac OS X scrolls by detecting the speed at which you roll the mouse wheel... msec between deltas or something, and then calculates the scroll distance.

Regards,
- Graeme -

________________________________________________
fpGUI - a cross-platform Free Pascal GUI toolkit
http://opensoft.homeip.net/fpgui/

I know what you mean, windows has (or had) a similar feature for moving the pointer (it would accelerate the movement).

So your point is, that for all other (non Mac) widgetsets, you want the widgetsets to emulate this?
IMHO the widgetset is the wrong place:

1) this would make the applications feel less native. And "NO", I am not implying that they are feeling 100% native now, but whatever amount of nativeness they have now, this would reduce it.

2) It could cause big problems, because if this is done in the widgetset, then this would be done with the assumption that such a feature does not exist under Win/Linux. The widgetset only gets what ever the OS is telling, the widgetset does not know, what the OS already did or did not do to the data.
Hence, if anyone has a driver that does exactly this under windows or Linux => and the widget set does it again, then scrolling would be unusable fast.

Therefore in my opinion this is an OS function, (on MAC), it shouldn't be part of the Widgetset. I wouldn't mind it on an application Level. Because then the application can switch it on or off, as the user requests (configurable), and that means if your OS (or mouse driver) does it, you do not have the application do it.

Best Regards
Martin

Interesting thread but I may have not asked the right question...

I'm trying to understand the scaling of the mousewheel as it affects the TScrollbar control specifically. Not for scrolling in SynEdit or case of scrolling text or similar purposes in a generic desktop application.

Instead I'm looking at using it to scroll other types of data (waveforms, images etc) on screen using a TScrollBar as the controlling widget where the scale at which the data moves definitely wants to be under application (not O/S or desktop preferences) control.

Am I to understand that this is currently outside the scope of LCL? IOW, is mousewheel scaling O/S defined and the application just has to accept the resolution of what it's been given on each platform?

TScrollBar defines LargeSize and SmallSize properties to specify how much to move when the Page Up/Down keys and arrow keys (among other things) are pressed. What I'm interested in is a similar mechanism to specify the resolution for mousewheel events instead of having them tied in some rubbery platform dependent way to the current TScrollBar.PageSize setting.

Does (or can) such a thing exist?

If not, then the Mac solution (with an application configurability option) certainly seems to be the best compromise.

Cheers, Bruce.

You can catch the scroll message in your application, and determine the action (and the scale) yourself.

Have a look at SynEdit:
    procedure WMVScroll(var Msg: {$IFDEF
SYN_LAZARUS}TLMScroll{$ELSE}TWMScroll{$ENDIF}); message WM_VSCROLL;

Best Regards
Martin

I am confused, do you want to use the scrollbar for scrolling or the mouse wheel?

If you want to use the mouse wheel, then use one of the OnMouseWheel* events. If you want to use the scrollbar, use the events of the scrollbar, if necessary.

If you don't handle the mouse wheel events, then the LCL widgetset interface or the underlying widget may translate the mousewheel to a scroll message.

Vincent

Vincent Snijders wrote

I am confused, do you want to use the scrollbar for scrolling or the mouse wheel?

I want to use the scrollbar because it provides visual feedback about the location of the section of the visible data in a larger buffer of displayable data. I prefer that the scrollbar perform this function regardless of whether the mouse wheel is moved (with the mouse pointer hovering over the scrollbar) or the scrollbar handle is dragged with the mouse or the arrow or page up/down buttons are used. All methods should to the same thing; move the data display in response to scrollbar events.

If you want to use the mouse wheel, then use one of the OnMouseWheel* events.

I can see that this is possible (at the application level) but it complicates the software design to have to handle these independently of the scrollbar (events from which are the canonic source of movement control in this application).

If you want to use the scrollbar, use the events of the scrollbar, if necessary.

This is what I'd like to do but the problem is that the scale at which the scrollbar moves in response to mousewheel events does not seem to be under my control (via properties or events of TScrollBar) other than via some rough relationship to PageSize. I can't set PageSize arbitrarily (to control the mousewheel movement scaling) because it's also used to indicate how much of the available data is being displayed at the present time.

If you don't handle the mouse wheel events, then the LCL widgetset interface or the underlying widget may translate the mousewheel to a scroll message.

This it indeed does (in GTK2 and Win32 at least). It's just not clear the mechanism by which the widget decides how far to move the scrollbar for each mousewheel event it translates.

Cheers, Bruce.

On windows the scroll offset is equal to the TMouse.WheelScrollLines. The value is set by reading the windows.SystemParametersInfo SPI_GETWHEELSCROLLLINES. Default is 3.

If you want to have something else, you have to handle the OnMouseWheel event.

Vincent

Thanks for the tip. I'll give it a go.

Bruce.

Still line oriented, but the treeview and the propertygrid (in the OI) do such a thing. It may be useful for examples.

Vincent

Excellent, thanks for the pointers!

Bruce.

You may hit the scrollbar position limits with really large data sets.

You can implement a common MoveTo method, which is called by both the scrollbar and wheel events, optionally by key events. For non-scrollbar events you should update the scrollbar position - what for itself may trigger the scrollbar event (don't remember).

DoDi