The documentation for scroll bars refers to how
scrollbars previously worked (but will no longer
work) which may explain why when I run an
application written for 1. customer  the scrollbars don't
behave correctly.  The way the maximum is described
is incorrect and following the description gives 
screwy results. The maximum is described as being
the left edge of the visible ( for horizontal)
which means you could have a maximum of zero (if
your visible area was your entire area). That is
not possible with the current implementation. You
cannot set maximum to zero and you can't set visible
to greater than maximum. So if you look at your
example you will see that what maximum should be
set to is 255 + 64 not 255. This behaviour is
consistent for Solaris 2.5 and Windows NT 4.0.

======================================================================

The workaround is setting maximum to what I
previously used for the maximum plus visible.
======================================================================

Yes, the behavior of  Scrollbar changed with JDK 1.1, but the specs
did not change.  Jeff Dunn verified that the change in behavior was
intentional.  Jeff writes:

"It turns out that there is a good reason to change the spec.
In the 1.0 model, if the visible size of the bubble changed,
the range of the entire scrollbar would also change, which
is not good. With the new model, the range of the scrollbar
does not change unless the programmer does it explicitly."

So, I updated the spec to accurately describe how the maximum
parameter works.


  xxxxx@xxxxx   1998-08-24

Here's a simple check that can be used to tell
whether Scrollbar is broken.  This can be used
by an applet to tell whether it should use the
specified workaround or not:
<pre>
private final static boolean sbBroken =
  (new Scrollbar(Scrollbar.HORIZONTAL,20,10,0,20).getValue() != 20);
</pre>

Currently on NT 4.0 the jdk1.1.5 applet viewer 
and Netscape Navigator 4.04 behave in a way not 
consistent with the docs, but MS IE 4.0.1 behaves 
consistently with the docs.  
Personally, I think the implementation should be
as described in the docs.  

I also investigated this problem (see bug number
4098739.)  However, the conclusion I came to is that
the fault lies in the Solaris JDK 1.1.x implementation.
The solaris 1.1.x appletviewer was the one case
I found where the behavior differed from the API
docs.  I did not test the appletviewer on other
platforms, but I tested both Netscape and MSIE
(on Solaris, Win95, WinNT, and the Mac) and the
browsers' behavior agreed with the API docs.

In the jdk1.1.5 source code for Scrollbar, there
is some validation checking of the supplied values
in the method "setValues(value, visible, minimum, maximum)".
All other methods for suppling values to the Scrollbar
use this method to validate the values supplied (there
is no way to avoid this method). In the validation 
checking is this code:
        if (visible > maximum - minimum) {
            visible = maximum - minimum;
	    }
The visible amount has nothing to do with the
minimum or maximum!
You can check to see if the visible amount is less
than zero, but there is no upper limit. The total
size of the Scrollbar is ((maximum - minimum) + visible)
What this means is that if the scrollbar visible amount
is greater than the maximum, the visible amount gets
screwed up, and then ALL the values are mixed up.
Can't we get this straightened out? I can't believe a
bug like this in an EXTREMELY valuable component hasn't
been fixed with the utmost priority.
Sorry, I don't have a workaround. I'm building my
own Scrollbar class.
Comments or suggestions, please send me a note
Steve Manley
smanley@geocities.com

In the JDK source (labelled 1.1_beta, dated 97/03/03) supplied with VisualAge
for Java (V1.0, Entry edition), the mehod
    SetValues(int value, int visible, int minimum, int maximum)
also includes the statement
    if (value > maximum - visible) {
        value = maximum - visible;
    }
This is the cause of the reported bug; the erroneous coercion of the visible
amount is at least consistent with this (wrong) interpretation of the API
documentation.
Regardless of which interpretation seems most logical to someone from one
background or another, the API docs have to win, given that code written to the
API used to work on 1.0.2 and still does on some platforms.

Aha !
I just read the 'fix' evaluation for bug 4012869. That 'fix' introduced this
bug - which should *not* have been classified as a 'doc' bug.
It looks as if bug 4012869 was due to inconsistent behaviour of the peer
classes for different platforms. There was no way to change java.awt.scrollbar
to produce the documented behaviour on all platforms, (the peer implementations
needed to be brought into line with each other) so the behaviour was quietly
changed to one that was easier to implement. 
Did whoever QA'd the fix not realise the API was being changed ? If they did,
why didn't the change get reported as an unavoidable incompatibility between
1.0.2 and 1.1 ?

Reported also as 4094136