JDK-4075484 : ScrollPane's adjustables only generate TRACK Adjustment Events
  • Type: Bug
  • Component: client-libs
  • Sub-Component: java.awt
  • Affected Version: 1.1.3,1.3.0
  • Priority: P4
  • Status: Resolved
  • Resolution: Fixed
  • OS: solaris_2.5.1,solaris_2.6
  • CPU: sparc
  • Submitted: 1997-08-29
  • Updated: 2003-03-14
  • Resolved: 2003-03-14
The Version table provides details related to the release that this issue/RFE will be addressed.

Unresolved : Release in which this issue/RFE will be addressed.
Resolved: Release in which this issue/RFE has been resolved.
Fixed : Release in which this issue/RFE has been fixed. The release containing this fix may be available for download as an Early Access Release or a General Availability Release.

To download the current JDK release, click here.
5.0 tigerFixed

Name: ggC50526			Date: 08/29/97

Run the code, watch the output.
No matter what is clicked on the scrollbar, only one Adjustment
Event type is generated - TRACK. There is never UNIT_* event
nor BLOCK_* generated.

import java.awt.*;
import java.awt.event.*;
public class MyFrame extends Frame
        ScrollPane pane;
        class comp extends Component {
                public comp(){}
                public Dimension getPreferredSize() {
                        return new Dimension(400,400);
        class AdjustmentAdapter implements AdjustmentListener {
                public void adjustmentValueChanged(AdjustmentEvent e){}
    AdjustmentAdapter adjustmentListener = new AdjustmentAdapter () {
             * Scrolls the column or row header depending on which scrollbar
             * in the scrollPane was clicked
            public void adjustmentValueChanged(AdjustmentEvent e) {
            if (e.getAdjustmentType() == AdjustmentEvent.BLOCK_DECREMENT)
            else if (e.getAdjustmentType() == AdjustmentEvent.BLOCK_INCREMENT)
            else if (e.getAdjustmentType() == AdjustmentEvent.UNIT_DECREMENT)
            else if (e.getAdjustmentType() == AdjustmentEvent.UNIT_INCREMENT)
            else if (e.getAdjustmentType() == AdjustmentEvent.TRACK)
        public  MyFrame() {
                add(pane = new ScrollPane(ScrollPane.SCROLLBARS_AS_NEEDED));
                pane.add(new comp());
        public static void main(String [] args) {
                MyFrame f = new MyFrame();

company - AT&T , email - ###@###.###

CONVERTED DATA BugTraq+ Release Management Values COMMIT TO FIX: tiger FIXED IN: tiger INTEGRATED IN: tiger tiger-b03

WORK AROUND Name: ggC50526 Date: 08/29/97 NONE ======================================================================

EVALUATION Problem reproducible with JDK1.1.5. xianfa.deng@Eng 1997-11-23 ======================================================================= The bug is still reproducible with JDK 1.3RA under Sun4 Solaris 2.7. sandeep.konchady@Eng 1999-12-15 Name: dmR10075 Date: 07/25/2002 When user scroll ScrollPane, we receive notifications in native code. Then we propogate these notifications to Java code by issuing PeerEvent which calls setValue() with new scrolling position on appropriate adjustable. ScrollPaneAdjustable.setValue() fires AdjustmentEvent for this change. The problem is that there is no way to pass scroll-type to setValue()(we can use only public api from peers, and setValue() only accepts 'int position') so it always fires AdjustmentEvent.TRACK. This happend for both Solaris and Windows as the code is absolutely the same. Note that for Scrollbar we fire AdjustmentEvent from the peer so we not the scroll-type. Unfortunately, we can't setValue() for ScrollPane because it will be very incompatible change. ###@###.### 2002-07-25 ======================================================================

SUGGESTED FIX A series of fixes were applied to the jtg sunsoft tree to make scrollpane post it's ItemStateChanged events in the peer, consistant with the other controls, these changes also fix this bug. below is an outline of the changes made: This problem is due to previous attempts to cause the ItemStateChanged event to be broadcast to the listeners. The comments to the previous deltas stated that the problem was that the Event Queue thread would not dispatch posted ItemStateChanged messages to the ScrollPaneAdjustable because it is not a Component. The previous fix was to not post the event, but to call the listeners directly from the setValue routine. The code before this delta even added a listener to itself, and called the peer's setValue routine from that listener. The approach in this fix is instead to fix EventDispatchThread to dispatch these events, and then allow the peer to post them. In order to do this a change is made to call ScrollPaneAdjustable.dispatch() in: src/share/java/java/awt/EventDispatchThread.java (sid 1.15). Then the ScrollBarAdjustable class must be changed from private to protected so it is moved to its own file, a dispatch routine was added, and the setValue routine was modified to call the peer directly in: src/share/java/java/awt/ScrollBarAdjustable.java (sid 1.1 and 1.2). The list of files was updated in: build/minclude/java_awt.jmk (sid 1.19). The ScrollBarAdjustable class and the listener were removed from ScrollPane in: src/share/java/java/awt/ScrollPane.java (sid 1.50). And finally the peer is updated to post the ItemEvents consistantly with all the other controls in: src/solaris/sun/sun/awt/motif/MScrollPanePeer.java (sid 1.17) andy.herrick@East 1998-03-05 Name: dmR10075 Date: 07/25/2002 I suggest to introduce new private method in ScrollPaneAdjustable which will accecpt both type and position information of scroll event and call this method from peer's native code. ###@###.### 2002-07-25 ======================================================================