Scrolling one direction only

Andy, Blair,

I "frequently" have need for scrolling in only one direction.  Sometimes, a
good answer is to use a scroller control, observe its changes, and move a
scrollee inside a "psueudo-scroller" (a container view with no layout
manager).  In most situations though, I'd like to take advantage of
ScrollingDecorator, but, with assurance that only one scroll bar will
appear.  Should I subclass, or is there a better way?

Have a good one,

Bill

--
Wilhelm K. Schwab, Ph.D.
[hidden email]

"Bill Schwab" <[hidden email]> wrote in message
news:abp3sv$jb5k3$[hidden email]...
> Andy, Blair,
>
> I "frequently" have need for scrolling in only one direction.  Sometimes,
a
> good answer is to use a scroller control, observe its changes, and move a
> scrollee inside a "psueudo-scroller" (a container view with no layout
> manager).  In most situations though, I'd like to take advantage of
> ScrollingDecorator, but, with assurance that only one scroll bar will
> appear.  Should I subclass, or is there a better way?

I think you will have to subclass/create a new class. I would have thought,
though, that your solution of having a scrollbar window that looks like a
normal scrollbar but is actually physically separate and (presumably) linked
by events might be somewhat easier to implement.

Regards

Blair

Blair,

> > I "frequently" have need for scrolling in only one direction.
Sometimes,
> a
> > good answer is to use a scroller control, observe its changes, and move
a
> > scrollee inside a "psueudo-scroller" (a container view with no layout
> > manager).  In most situations though, I'd like to take advantage of
> > ScrollingDecorator, but, with assurance that only one scroll bar will
> > appear.  Should I subclass, or is there a better way?
>
> I think you will have to subclass/create a new class. I would have
thought,
> though, that your solution of having a scrollbar window that looks like a
> normal scrollbar but is actually physically separate and (presumably)
linked
> by events might be somewhat easier to implement.

Fair enough, but there are some negatives too:

(1) the scrollbar range/size logic is not trivial (it's not horrible either
of course), so I'm trying to reduce the duplication; being able to use
ScrollingDecorator, or a sub-class, in all cases would be a plus
(2) the scroll bar control insists on flashing when it has the input focus.
Some users have found this either annoying or simply unsettling.
(3) the flashing has been known to cause screen scarring when the scroll bar
parameters change; I find this one unsettling whether or not it bothers the
users :(

The flashing appears to be impossible to deactivate:


http://msdn.microsoft.com/library/default.asp?url=/library/en-us/winui/scrol
bar_48dv.asp

Anyone care to prove me wrong? I'd be most grateful :)

Have a good one,

Bill

--
Wilhelm K. Schwab, Ph.D.
[hidden email]

"Bill Schwab" <[hidden email]> wrote in message
news:abrnom$kh6a9$[hidden email]...
>...
> (2) the scroll bar control insists on flashing when it has the input
focus.
> Some users have found this either annoying or simply unsettling.
>...
> The flashing appears to be impossible to deactivate:
>

I wonder if you could use a similar technique we use to implement "static"
text edit controls, which is essentially to pretend that the window is
transparent thus preventing it getting focus. I think that doing exactly the
same thing may prevent it from fulfilling its function at all, but there may
be a way to prevent it from getting keyboard focus yet allowing it to
respond to mouse input.

Regards

Blair

Hi Blair,

> I wonder if you could use a similar technique we use to implement "static"
> text edit controls, which is essentially to pretend that the window is
> transparent thus preventing it getting focus. I think that doing exactly
the
> same thing may prevent it from fulfilling its function at all, but there
may
> be a way to prevent it from getting keyboard focus yet allowing it to
> respond to mouse input.

My early attempts at taking the focus away from it were disasterous, but, I
never thought of preventing the focus from reaching it.  I'll keep that in
mind, but, I'm increasingly liking the subclassing idea; it's not elegant,
but, it could easily end up being simpler, and it reuses a well-tested
scroller.

Have a good one,

Bill

--
Wilhelm K. Schwab, Ph.D.
[hidden email]