Controlling scrollbars

  • Thread starter Thread starter sb
  • Start date Start date
S

sb

Let's say you have a simple UserControl (2.0 framework) with the following
two settings changed from their default:

AutoScrollMinSize = 16384;
AutoScroll = true;

Once those are set, is there a way to also set the LargeChange and
SmallChange properties of the horizontal/vertical scrollbars to something
other than what the framework determines them to be? It seems that once you
set these AutoScroll values, changes to the scrollbar's Small/LargeChange
properties have no effect.

Essentially, I want the SmallChange to be 16 and the LargeChange to be some
larger number that is also divisible by 16 (based on the clientwidth). That
way when I paint my 16x16 images in the client area, the left/top edges
aren't cut off. You can picture my application being a game editor for
level files that consist of 16x16 tiles.

TIA!
-sb
 
sb,

AutoScroll feature sets this internaly so the large change is always the
size of the page and cannot be controlled (that's why it is called *auto*).

You need to do your own scrolling. If you you do it as autoscroll does it,
it shouldn't be that difficult. Just make the control where you paint your
images as big as you need, add scroll bars and when the scroll position
changes change the location of the control accordingly.
 
I've already done it manually using the ScrollWindowEx, SetScrollInfo and
Get/SetScrollPos win32 calls...I was just looking for something cleaner.

Even though it's "auto", I don't see why MS chose not to allow an app to
adjust the scrollbars line/page scroll values. There's no technical reason
why it can't be done. What stinks even more, I can't get a handle to their
scrollbars and just use SetScrollInfo to do it myself.

Thanks!

-sb
 
sb,

Autoscrolling doesn't work doesn use the ScrollWindowEx approach. It simply
changes the location of the contained controls.
 
I'd like to add that I tried your suggestion below several weeks ago. The
problems I had with adding ScrollBars were:

a) The .Net ScrollBar controls seemed to get painted slower..causing a
noticable flicker that I could not resolve.
b) More calcs were needed to account for scrollbar heights/widths in
order to ensure that I didn't paint under them
c) Painting the sizegrip by hand using ControlPaint.DrawSizeGrip never
really "looked right"
d) Mousing code had to be adjusted to account for the scrollbars
controls
e) Can some system metric value get changed by the user and screw
everything up?

In the end, I think handling WM_VSCROLL and WM_HSCROLL messages directly
ended up being the cleanest. I don't have to worry about any of the above
and I have full control over all scrolling. I can post the WndProc code if
anyone's interested...in the end, it's not that complex really and it even
accounts for zoom with a simple bitshift.

Anyway, I was hoping I could use the built-in autoscrolling features since
the framework does most of what I wanted already. That was wishful
thinking!

Thanks :)
-sb
 
I'm not sure I follow...

ScrollableControl does use ScrollWindowEx depending on what you're doing.
For my purposes, I only need to scroll to a certain position (not a
control). If I set AutoScrollPosition to whateverX,whateverY my scrollbars
will be adjusted accordingly and I can base my paint code off of their new
positions. Using that property does involve a call to ScrollWindowEx.

-sb
 
Back
Top