JDK-6458700 : WinLaF : Vista : JScrollbar button updates on rollover instead of entire scrollbar
  • Type: Bug
  • Component: client-libs
  • Sub-Component: javax.swing
  • Affected Version: 6
  • Priority: P4
  • Status: Resolved
  • Resolution: Fixed
  • OS: windows_vista
  • CPU: x86
  • Submitted: 2006-08-09
  • Updated: 2017-05-16
  • Resolved: 2006-08-23
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.
JDK 6
6 b97Fixed
Related Reports
Relates :  
JDK-6462156 - Vista: JScrollbar hover behavior incomplete
Relates :  
JDK-6461337 - Win Vista: ScrollBar buttons are not animated correctly
Description
In a native Vista applications when the user moves the mouse over a scrollbar button all the of the internal scrollbar comopnents change the state (the thumb, the buttons at the end, the track, etc).  In Swing only the button the mouse is over has the state changed.
Comments
EVALUATION Initial thoughts: On Vista there are new HOVER states defined for the buttons. This state appears to mean that if another attached component is in the HOT state then this component is in the HOVER state. In other words, it's the rollover state when you should show an effect but the mouse cursor isn't actually over you. An example of this is the native Vista scrollbar. When the mouse moves over the thumb in the middle of the bar the buttons at the ends will repaint to show a rollover effect. Since the thumb already as a mouse listener it should be possible to modify it to include this effect. It would trigger a repaint on the buttons (or perhaps just the entire scrollbar). When the buttons are repainted they will calculate their STATE based on the button model. They could also take into account the state of their associated thumb. If the thumb == HOT then they should be in HOVER. This same logic should be applied to the thumb and the other button as well, so that they all move into the HOT and HOVER states together. Once in the HOVER state the components should draw appropriately. To ensure this behavior only happens on Vista the code should check that the HOVER state is actually on each affected component, since that state doesn't exist in previous versions of Windows.
15-08-2006