Vertical Scrollbar .LargeChange bug

[Richard Kucia]

My testing indicates that there's a bug in the vertical scrollbar.

When the .LargeChange property is greater than 1, then the maximum value at
runtime that can be obtained, either by clicking the bottom arrowhead or by
dragging the thumb, is less than the numerically allowed range. Examples:

.Minimum = 0, .Maximum = 140 and .SmallChange = 1 in all examples

If .LargeChange = 1 -- then everything's OK.
If .LargeChange = 16 -- then the maximum .Value that can be obtained is
125.
If .LargeChange = 32 -- then the maximum .Value that can be obtained is
109.

Can anyone confirm this behavior? Thanks.

I wouldn't be surprised if the horizontal scrollbar also suffered from the
same disease....
--
Richard Kucia

[Armin Sadeghi [MSFT]]

Richard,

The behaviour you have described is not a bug. If you examine the situation
you are actually trying in all cases to scroll past the maximum value that
you have set. In this case 140 is your maximum and with 16 and 32 you would
exceed the 140 Maximum value. 125+16 = 141 and 109 + 32 = 140, both of
which are greater than 140 and thus not allowed. In other words the maximum
Value that you reached was the greatest multiple of LargeChange for the
difference between your initial value and the Maximum.

To resolve this problem you could set the largechange value to a multiple
of the Maximum value.

Hope that helps,
Armin

This posting is provide "AS IS" with no warranties, and confers no rights.
--------------------
| From: "Richard Kucia" <rjk...@worldnet.att.net>
| Subject: Vertical Scrollbar .LargeChange bug
| Date: Fri, 10 Jan 2003 18:04:00 -0500
| Lines: 22
| X-Priority: 3
| X-MSMail-Priority: Normal
| X-Newsreader: Microsoft Outlook Express 6.00.2800.1106
| X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106
| Message-ID: <#EuZbzPuCHA.2636@TK2MSFTNGP11>
| Newsgroups: microsoft.public.dotnet.framework.compactframework
| NNTP-Posting-Host: 179.cleveland-18-19rs.oh.dial-access.att.net
12.87.135.179
| Path: cpmsftngxa06!TK2MSFTNGP08!TK2MSFTNGP11
| Xref: cpmsftngxa06
microsoft.public.dotnet.framework.compactframework:13962
| X-Tomcat-NG: microsoft.public.dotnet.framework.compactframework

[Richard Kucia]

Armin,

I respectfully disagree. If the properties are set as described and I drag
the thumb all the way to its maximum position, I would expect the value to
be the maximum value. I understand that clicking in the "LargeChange" area
should not produce a value greater than the maximum, but in my opinion not
being able to reach the maximum value is also not the best design.

Here's how I would do it:

* Dragging the thumb to the top produces the .Minimum value.
* Dragging the thumb to the bottom produces the .Maximum value.
* Clicking in the LargeChange area (above or below the thumb) or clicking an
arrowhead causes the corresponding increment/decrement operation, but then
the result is capped so that .Value is always within range.

In my particular app, I cannot predict the range (.Maximum - .Minimum), and
therefore it's not always possible to have a convenient integer factor of
the range. The range could even be a prime number!

Just out of curiosity...what about the scrollbars in Windows apps? As far as
I can tell, when I click a scrollbar in, say, Word, when the scrollbar is
fully extended, the document window is fully at the bottom. Since the
document window is resizable to any height, the "integer factor" approach
wouldn't work. This leads me to suspect that the .Net scrollbars and the
Windows apps scrollbars are different animals. Right?

Thanks for replying.

Richard Kucia

"Armin Sadeghi [MSFT]" <asad...@online.microsoft.com> wrote in message
news:QeYJcLQuCHA.1628@cpmsftngxa09...

[Hilton]

Armin,

Richard already gave good arguments why this behavior doesn't seem to be
correct.

You say that making the large value a multiple of the maximum value is a
solution. As Richard pointed out, the maximum value could be prime, also
the user could use small changes before using large change, then you logic
no longer applies.

The logic: value = Math.Max (value + largeChange, MaxValue) should be used
IMHO.

Hilton

"Armin Sadeghi [MSFT]" <asad...@online.microsoft.com> wrote in message
news:QeYJcLQuCHA.1628@cpmsftngxa09...

[Richard Kucia]

Thanks for the support.

Treeviews and listviews automatically display scrollbars as necessary, and
those scrollbars don't have this problem! Why should we have to endure it in
the scrollbar control itself? C'mon MS -- admit that it's a bug and schedule
it to be fixed.

Richard

"Hilton" <hiltong...@mindspring.com> wrote in message
news:Oj5SYhzuCHA.2372@TK2MSFTNGP12...

[Hilton]

Hi,

My concern is that behaviors do not match Windows (on PC). I've had to code
many workarounds - the VScrollBar being one of them. Surely Microsoft have
a nice thick doc of control behaviors - right? So, the CF team should just
follow that and not introduce any different logic.

My 5c...

Hilton

"Richard Kucia" <rjk...@worldnet.att.net> wrote in message
news:#V9TtmLvCHA.2448@TK2MSFTNGP11...

[Chris Lorton [MSFT]]

Richard,

Armin's explanation might not have been sufficiently clear, however, the
behavior you are seeing is by design and is not a bug. Here's the
situation:

For a vertical scrollbar, LargeChange maps to the "page height." In your
example, you've claimed your "document" is 140 units tall and the
screen/viewport into that document is 16 units tall. Let's say that the
units you are using are lines of text. Thus, the largest ScrollBar.Value
that you will see is 125 (as you've discovered) because when line 125 is at
the top of your screen/viewport, the "bottom" of your document just fits
(16 lines starting at line 125 means line 140 is the last visible line).

If the ScrollBar.Value was larger than 125, "empty" space would have to be
displayed at the bottom of your screen/viewport. This behavior perhaps is
not required with a "document" since you might not mind seeing blank lines,
but let's consider a custom PictureBox control:

Assume the control is 128 pixels wide by 128 pixels tall.
Assume the image in the control is 500 pixels wide and 128 pixels tall.

The control does not need to display a vertical scroll bar because the full
height of the image is visible.
The control _does_ need to display a horizontal scroll bar because the
image is wider than the control. (We'll ignore whether or not showing the
horizontal scrollbar now makes a vertical scrollbar necessary, i.e. the
horizontal scrollbar is "outside" the bounds of the control).

Set the range of the horizontal scrollbar to Minimum = 0 and Maximum = 499
(500 pixels).
Now, on ScrollBar.ValueChanged events, the image can be painted at x =
-ScrollBar.Value and y = 0. As the scrollbar moves right, the image moves
left. Unfortunately, when the scrollbar value becomes 499, the image is
all the way off the left side of the control.

By setting LargeChange to 128 (the width of the control), the largest
Scrollbar.Value encountered will be 500 - 128 = 372. At that point, the
right side of the image will come into view and the rightmost column of
pixels from the image is just visible on the right side of the control.

I hope this helps.

-Chris

This posting is provided "AS IS" with no warranties and confers no rights.

--------------------
| From: "Richard Kucia" <rjk...@worldnet.att.net>

| References: <#EuZbzPuCHA.2636@TK2MSFTNGP11>
<QeYJcLQuCHA.1628@cpmsftngxa09> <Oj5SYhzuCHA.2372@TK2MSFTNGP12>
| Subject: Re: Vertical Scrollbar .LargeChange bug
| Date: Wed, 15 Jan 2003 12:13:10 -0500
| Lines: 109

| X-Priority: 3
| X-MSMail-Priority: Normal
| X-Newsreader: Microsoft Outlook Express 6.00.2800.1106
| X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106

| Message-ID: <#V9TtmLvCHA.2448@TK2MSFTNGP11>
| Newsgroups: microsoft.public.dotnet.framework.compactframework
| NNTP-Posting-Host: 86.cleveland-18-19rs.oh.dial-access.att.net
12.87.135.86
| Path: cpmsftngxa06!TK2MSFTNGP08!TK2MSFTNGP11
| Xref: cpmsftngxa06
microsoft.public.dotnet.framework.compactframework:14279
| X-Tomcat-NG: microsoft.public.dotnet.framework.compactframework