Name: dsC76792 Date: 10/05/99

###@###.###

Scrollpane behavior is inconsistent if a scrollpane's adjustable
has an AdjustmentListener that in responce to any AdjustmentEvent
sets adjustable's value to some fixed value.

On win32 when you try to scroll the scrollbar thumbs are moved
but the contents isn't moved. I saw it on JDK1.3.0-G.

On solaris it depends on the Motif version JDK is build with:

With Motif 1.2 the scrollbar thumbs and the contents are moved
as if there is no AdjustmentListener at all.
I saw it on JDK1.3.0-G.

With Motif 2.1 when you try to move a scrollbar thumb, scrollbars
and the contents starts jumping back and forth.
I saw it on our current kestrel workspace when built with Motif 2.1.
If i build it with Motif 1.2 it behaves the same way as JDK1.3.0-G.

The following test case reproduces the problem:

------------------------------------------------------------------
import java.awt.*;
import java.awt.event.*;

public class Test extends Frame implements AdjustmentListener {

    public final ScrollPane scrollpane = new ScrollPane();

    public Test() {
super("Frame");
scrollpane.add(new Component() {
public Dimension getPreferredSize() {
return new Dimension(500, 500);
}
            public void paint(Graphics g) {
                g.drawLine(0, 0, 500, 500);
            }
        });
        add(scrollpane);
        scrollpane.getVAdjustable().addAdjustmentListener(this);
        scrollpane.getHAdjustable().addAdjustmentListener(this);
    }

    public void adjustmentValueChanged(AdjustmentEvent adjustmentevent) {
        scrollpane.getVAdjustable().setValue(20);
        scrollpane.getHAdjustable().setValue(20);
    }

    public static void main(String args[]) throws Exception {
Frame frame = new Test();
frame.pack();
        frame.addWindowListener(new WindowAdapter() {
            public void windowClosing(WindowEvent e) {
                System.exit(0);
            }
        });
        frame.setVisible(true);
    }
}
-----------------------------------------------------------------------

It looks like win32 behavior is more correct.

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