Starting the Scrollbars

Finally made a start on the vertical scrollbar. There’s a single vertical scrollbar floating around in the demo which shows the progress so far. I’ve got a gutter and a grip implemented. The gutter is represented by the new “ScrollbarVertical” gadget, creating an instance of which will provide a scrollbar without up/down buttons. There’s also a header file for a “ScrollbarVerticalComplex” gadget, which will be a gadget that contains a ScrollbarVertical and the up/down buttons.

The gadget behaves as you’d expect - click and drag the grip, or click the gutter to make the grip jump its own height up or down the gutter. I’d initially built it so that the grip jumped straight to the stylus location when the gutter was clicked, but I checked out the behaviour of Windows and realised that the usual way of handling this was to move by a single grip height.

At the moment I’m just getting the UI built, so it doesn’t interact with any other gadgets yet. The current plan is to have the scrollbar interact with an object that inherits from a new “ScrollableBase” class, which is basically an interface representing the features of a scrollable box. However, it’s just occurred to me that this won’t be a good solution if I want the scrollbar to double up as a slider gadget (gahh, I should have thought of this before - it throws all the class names out). It might be better if the scrollbar fired a scroll event in its event handler instead.

Any thoughts?

It’s interesting to note that the Woopsi framework is actually doing most of the work for me now. Putting the scrollbar together has just been a case of knitting together existing functionality.

In other Woopsi news, I’ve tidied up the TextBox’s click() and release() functions a little.


Replaced the “target” ScrollableBase idea with a simple EventHandler structure instead. There’s a new scroll event defined in the EventHandler enum, and the scrollbar just sends a scroll event to its event handler when the grip is dragged or the gutter is clicked. It sends the scroll distance as the x and y event arguments.

I’ve also sorted out the scrollbar colours.


Jeff on 2008-01-17 at 20:07 said:

I don’t see the need for a special class for the Scrollable - just send events via the standard EventHandler.

Specifically, remember that some windows will want a horizontal AND a vertical scroll bar. As soon as you need to pass the actual scrollbar in the message to the scrollable, you’ve invalidated the benefits of a specific base class.

But you’ve obviously worked that out for yourself…


When you send the ‘scroll distance’, is it as a percentage of the scrollbar, or an absolute number of pixels? The first is preferable, though subject to rounding errors during division; the second requires the scrollbar owner to do some non-intuitive math involving characteristics of the scrollbar it shouldn’t have to know.

Personally, I’d be going with option 3 which says “my new absolute position is now Y which I promise is between the Ymin and Ymax that you told me earlier”. If the Scrollable wants to do fancy scroll up/down operations, it can still look at its own copy of the old Y and compare it with the new to decide how to animate…

ant on 2008-01-17 at 22:20 said:

Scroll distance currently means an absolute number of pixels. For option 3, you mean that you’d prefer the x and y co-ords of the grip returned rather than the distance it’s moved?

Wiring everything up is the next thing on the list.

jeff on 2008-01-18 at 02:49 said:

No, I’d rather I could tell the scrollbar a MIN, MAX and CURRENT value and it managed the mapping from those values to on-screen pixels.

That way, you can tell the scrollbar that it should change its physical pixel size (by a window resize, or some such) and it should automagically recompute the size/position of the grip.

For example, I might have five lines in my list, each of which is 100 pixels tall. I want the scrollbar to scroll through “lines”, not “pixels” so its most convenient for me if I tell it (min=0,max=4) and then it will scroll back/forward through LINE numbers, not pixels. The user really doesn’t need to get smooth scrolling all the way through the range (ie, you can’t position to line 3.6)

I can see where a scrollable bitmap might like the scrollbar to talk in absolute pixels, but thats the trivial case.

ant on 2008-01-18 at 14:02 said:

Aha, that’s the solution I was looking for. Done!