JDK 1.1.1, 1.1.2 and 1.1.3 for Window NT version.
From Customer's email:
Under 1.1.1 and 1.1.2, you can lock the program by grabbing the
scrollbar tab and moving the cursor inside and outside of the scrollbar
region vigerously, eventually the setValues call will lock up the
Under 1.1.3, it doesn't lock, but in _all cases I never get the
mouseReleased event_. Furthermore (not crucial, but annoying) I now
have to explicitly call setValue in response to an adjustment event to
make sure the thumb 'sticks' in the proper spot.
<<Scroll 'lag' issue:>>
Under 1.1.1, 1.1.2 and 1.1.3 if I spend too much time in the adjustment
event a huge cache of events starts stacking up underneath me.
Specifically, I repaint on a scroll and sometimes it can take on the
order of 100 ms to redraw. If the user grabs the thumb and moves it a
lot, quite a few messages get queued up and he spends a long time
sitting around watching data scroll by. Is there any other than
starting a second thread to solve this problem? Like dumping all but
the last event?
Under 1.1.1, 1.1.2 and 1.1.3 if I move the scroll bar thumb around a
_lot_ the arrow icons turn black and the thumb starts jumping around
<<Blinking focus issue:>>
Under 1.1.1, 1.1.2 and 1.1.3 when I issue a setValues call the blinking
'focus indicator' does not follow along with the new values and remains
too large. To clarify, the focus indicator is a block just smaller than
the thumb tab which blinks inside of the tab -- when the tab shrinks or
grows, this indicator does not.
The primary problem _was_ the locking, which until yesterday's
acquisition of 1.1.3 was killing me -- I'd like to note that somehow
Sun's HotJava browser got around this problem under 1.1.1/1.1.2 by
(seemingly) disallowing any modifications of scrollbar parameters while
the user is moving the thumb around. This works but has an annoying
side-affect of 'freezing' the scrollbar from background updates while a
user moves it. Again, this part has been fixed in 1.1.3 but I thought
it was interesting, and for over a week I was trying (unsuccessfully) to
duplicate this HotJava behavior.
The primary problem now lies in the lack of released events, the
strange erratic behavior with the black icons/jumping thumb tab, and the
lagging focus indicator. Through 1.1.3 we can ship customers a working
product, but it still looks unprofessional -- I want to remedy this.
And the sample test case is as following:
* $History: $
public static void main(String argv)
Frame frame = new TestFrame();
class TestFrame extends Frame implements MouseListener, AdjustmentListener, Ru
Scrollbar scrollbar = new Scrollbar();
int maxval = 100;
scrollbar.setValues(0, 10, 0, maxval);
setBounds(0, 0, 300, 300);
public void run()
} catch(InterruptedException io)
maxval += 10;
scrollbar.setValues(scrollbar.getValue(), 10, 0, maxval)
public void mouseEntered(MouseEvent evt)
public void mouseExited(MouseEvent evt)
scrollbar.setValues(scrollbar.getValue(), 10, 0, maxval);
public void mousePressed(MouseEvent evt)
public void mouseReleased(MouseEvent evt)
public void mouseClicked(MouseEvent evt)
public void adjustmentValueChanged(AdjustmentEvent evt)
System.err.println("adjust: " + evt.getValue());
} catch(InterruptedException io)
Please note that:
The reason I increment maxval in my second thread is for
three reasons: to decrease the thumb buffer size to demonstrate the
thumb focus bug, for visible feedback that the thread is updating the
scrollbar, and to avoid any possible caching of variables that would
throw out a setValues() request on the basis of variables being
identical to the last set that were passed in.
Specifically, grab the thumb with your mouse, without releasing
the mouse button move the cursor _outside_ of the scrollbar but not so
far that you can't still move the scrollbar. Now, move the scroll bar
up and down and sooner or later your thread will lock.