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. Martin Friebe wrote: > Graeme Geldenhuys wrote: >> 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. >> > 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 > > -- > _______________________________________________ > Lazarus mailing list > Lazarus@lists.lazarus.freepascal.org > http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus -- _______________________________________________ Lazarus mailing list Lazarus@lists.lazarus.freepascal.org http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus