I have a control (an edit table) that must be scrollable (in the vertical direction), but for various reasons I must use a separate scroll bar and keep the two controls in synch with some programming.

Now it turns out I might need somewhat more information about the scrolling action than the Value (i.e, position) parameter of the VSCROLL (HSCROLL) event has to offer. I'd like to know when one of the scroll bar's arrow buttons has been clicked. I'd like to know when the shaft has been clicked. And it seems I need to know when the thumb has been slid, along with the old and new position of the thumb.

In this very interesting article a Sprezzatura employee describes how to qualify events for a scroll bar, opening up the new possibilities I want. But it seems the article only applies to scroll bars of other controls, not to a separate scroll bar. Has anybody got any ideas on how to "hack into" a scroll bar control?

- Oystein -

Think I got around the problem for now, but I'm certain it'll raise its head on a later occasion. So if anybody knows a solution I'd like to know.

- Oystein -

How about creating a second edittable with :-

No Column headings

No Row Numbers

Vertical Scroll Bar

0 width for the one and only column.

All you are left with is a scroll bar. Is that what you are looking for?

Robert,

No, no, no, nooooooooooo!!! Not another edit table!!!!!!!!!!!

I have thought of this solution already, but I think it creates its own problems.

Let's say I have a large number of hits in my result list. Let's say I keep 200 of them in the edit table (my original edit table) at any time, and 20 of them visible.

Now tell me how many rows that second edit table should have. As many as there are hits in the list? That's what's easiest to implement, with the least amount of counting and calculations. But it will set a limit to the size of the result list. If the result list contains N hits, the second edit table will have to contain N-1 delimiter characters. So if the result list is large enough - with more than 64K hits - the approach breaks down.

Alternatively, when the result list is large, the second table could have fewer rows than the result list has items, e.g, only a tenth as many rows. But what should then happen when the user clicks once on one of the scroll bar arrows? Should the (first) edit table scroll by more than one line (ten lines)? That's not what the user expects.

The solution to this new problem could be to set the scroll of the second table back again a bit all the time. But it could easily create a lot of jitter. Tricky.

But perhaps it could be done….

Come to think of it - there's one attractive feature pure scroll bar controls lack, and that's "page-wise" scrolling. Click in the shaft of a scroll bar control and the b** scrolls only one line. The scroll bars of other controls can scroll one "page" at a time. But this could increase the jitter. I think the second edit table would need very many rows to keep the jitter at a minimum.

But perhaps it still could be done….

Thanks for the exchange of ideas!

- Oystein -

View this thread on the forum...