What is the logic behind the thumb size and position calculation in scroll bars?


Commenter sarathc asks, "How do we implement a custom scroll bar as Windows does? What is the logic behind the thumb size and position calculation? How we could dynamically manage it?"

Let's look at the three questions in turn.

To implement a custom scroll bar... don't do it. It's just not worth the effort, and there will almost always be little seams, like not lighting up when the mouse hovers over them.

The logic behind the thumb size and position calculation I thought I covered in my scroll bar series. The size of the thumb relative to the size of the scroll bar is the same as the page size relative to the scroll bar range. In other words:

thumb size / scroll bar size = page size / scroll bar range

A little high school algebra tells you, then, that

thumb size = scroll bar size * page size / scroll bar range

There may be some off-by-one errors in the above formula, and some special tweaks for extreme cases (you don't want a thumb smaller than one pixel after all), but that's the basic idea.

Similarly, the screen position of the thumb relative to the scroll bar is equal to the programmatic thumb position relative to the scroll bar range (roughly).

To dynamically manage it, use the usual scroll bar functions like SetScrollInfo.

Comments (16)
  1. Medinoc says:

    By “scroll bar size” here, you mean buttons excluded, don’t you?

    [Answering this question is left as an exercise. -Raymond]
  2. This is common sense. I have my own library of customizable/skinnable windowless controls, including, of course, an scroll bar, and coming up with the formulas was quite easy: it only took me five minutes or so.

  3. configurator says:

    I hate custom scrollbars. They never work properly – either they don’t respond properly to mouse events, or they don’t respond to the mouse wheel, or they respond to some wheels and not others. And if you have your TouchPad configured to scroll your windows it usually won’t work. Broken scrolling makes it non-trivial to scroll – once you have to actually think "Now what do you have to do to see the rest of the text", then aim your mouse at the usually more aesthetic yet smaller scrollbar, you lose continuity of the document or whatever it is you were reading.

  4. WndScks says:

    And even less known than hover and mousewheel; the context menu (damn you firefox and opera!)

  5. Valters says:

    I really wish the calculation also included some mimimum size that thumb bar does not ever shrink.

    You mention that formula should not shrink the thumb to less than one pixel – I say, one pixel is not reasonable size for human UI. The thumb should be at least size of … say, the mouse pointer, – so that I can grab the thumb easily to drag it.

    Observe: there is small window, that has a lot of content (we open a large file in Notepad). The only reasonable way to navigate, is to grab the scrollbar’s thumb with mouse, and drag it. (Page up/page down is too slow, scrolling by clicking arrow or scrollbar space is even slower). To grab thumb, you need to position mouse on thumb … but thumb has shrunk to 2-3 pixels height! Totally unreasonable, and really difficult to put mouse in that 2 significant pixels, to grab it. Basically, thumb becomes useless at these extremely small sizes.

    I say again – there ought to be mimimum size, and scrollbar’s thumb should never become smaller than this size. Size should be determined by usability – the smallest size where it still is easy is to grab it.

  6. Mark says:

    Another piece of chrome usually overlooked is the fade on hover.  This is enough to identify practically all applications with custom scrollbars, including, appropriately enough, Google Chrome.

    Valters: on Vista, the minimum is 15px, and I believe XP’s is around 6px.  Are you still using Windows 98?

  7. Neil says:

    The minimum thumb size does not appear to be accurately reflected in the system metrics if you are using a Classic theme; for some reason the actual value is half the metric.

  8. Jules says:

    Are all these effects people are talking about Vista-only?  I have XP, and don’t see scroll bars lighting up, or fading, or anything like that…

    Which brings about another problem with replacing the standard controls: often they should behave differently on different OS versions.

  9. ender says:

    Are all these effects people are talking about Vista-only?  I have XP, and don’t see scroll bars lighting up, or fading, or anything like that…

    They don’t light up with the non-fisherprice theme.

  10. David Walker says:

    Custom scrollbars rarely repect the WIDTH setting that can be set in Display Properties.  I sometimes adjust that, and dang it, the whole user interface is supposed to use it.  Don’t reinvent the wheel (so to speak).

  11. mikeb says:

    > And even less known than hover and mousewheel; the context menu (damn you firefox and opera!)

    Holy Crap!  Lesser known indeed.  I wonder if I’ll ever use it now that I know it’s there?

  12. 640k says:

    There may be some off-by-one errors

    Yes, in Windows 2000 there is.

  13. Joe Sixpack says:

    I concur with @Valters, the min height should never be less than its width for vertical bars.  Its aggravating  enough when someone crams 1000’s or items in a tiny listbox that can’t be sized but then you compound the frustration with a thumb size too small to grab.  Then of course when you miss it, the list shoots exceedingly far from where you want to be.  

  14. MadQ says:

    I’m with James Schend. Please don’t roll your own common controls. You won’t get it right. I’ve created few accessibility tools for my own use, and had to resort to all kinds trickery and jump through flaming hoops to get them to work with several applications. I’ll never release these tools to the public. I would be inundated with "it doesn’t work with application X" bug reports.

    I’ve been on the other side of it too, where I had written apps in BASIC language Y. None of the common controls worked with a blind employee’s screen reader because all common controls were superclassed. All the screen reader would say were superclass names (as in yyyyyyyBUTTON, except the ‘y’s were a specific word).

  15. James Schend says:

    Out of curiosity, Antonio, have you tested all your custom skinnable widgets with voice recognition, or with pen input? Did they work correctly in both cases?

    If you can pull off *correct* scrollbars, more power to you. But from my experience, most people who write custom widgets don’t bother to test ever case, and they’re rarely fully correct.

    One of the reasons I try to avoid open source applications on Windows is that they usually use GTK widgets, which don’t support jack– they don’t support pen input, they don’t support voice recognition, they don’t support even the normal Open/Save dialogs.

  16. Anonymous Coward says:

    WndScks: and Chrome – it too doesn’t support the context menu, worse, a different menu (for the page) pops up, it’s very off-putting, especially because I use it a lot in other apps when my keyboard is lying under my desk and I tend to forget that in Chrome it doesn’t work.

    I agree in principle with all people who warn against reimplementing operating system controls, but there are some cases where I can see why they did it.

    Internet Explorer, and as has been pointed out, many other browsers reimplement controls. Presumably this is to prevent a buggy/heavy webpage from exhausting the user heap, and perhaps to be able to apply certain CSS attributes that aren’t supported by the default versions. Whether these attributes should be supported in the first place is another matter.

    Secondly, most games implement their own UI. While it is possible to use the layered window API to slurp window contents to textures, the performance penalty is usually too steep. There are ways to work around that, in theory, but those are tricky so people just roll their own.

Comments are closed.

Skip to main content