blockLocationToScrollDown/Up use of constant for adjustment to track point results in un-usable values

[croesch]

Issue by David Bradley from Sat, 16 Apr 2011 07:46:08 -0500 Originally opened as http://jira.codehaus.org/browse/FEST-438

---

Using class JScrollBarLocation to get a point in a scrollbar track provides un-usable point value. Looking at the code a constant (BLOCK_OFFSET = 4) is used in blockLocationToScrollDown/Up and is an adjustment to the unitLocationToScrollDown/Up. The latter providing a mid-point in the arrow button.

However, in Swing the default size of an arrow button is 16x16, so unitLocation..... gives 8x8 but blockLocation results in only 4 being adjusted from the mid-point, which still resides in the arrow button.

If the scrollbar is not of the default size, the use of BLOCK_OFFSET would likely be more out of whack.

current code looks like:

class JScrollBarLocation
-------------------------

private static final int BLOCK_OFFSET = 4;

@RunsInCurrentThread
  public Point blockLocationToScrollUp(JScrollBar scrollBar)
{
    Point p = unitLocationToScrollUp(scrollBar);
    int offset = BLOCK_OFFSET;
    return blockLocation(scrollBar, p, offset);
  }

Something like below is needed

@RunsInCurrentThread
  public Point blockLocationToScrollUp(JScrollBar scrollBar) {
    // provide a point just off the edge of the arrow button (unit location)
    Point p = unitLocationToScrollUp(scrollBar);

    // offset from the arrow to the track is a factor of
    // scrollBar's orientation width/height
    int offset = 0;

    if( scrollBar.getOrientation() == VERTICAL)
{
         offset = scrollBar.getWidth();
    }
else
{
         offset = scrollBar.getHeight();
    }

    // assume offset represents the arrow's button square size as
    // drawn, the track offset is at the edge of the button (offset/2) and a
    // little further (+2) for inset/border consideration in the most simple
    // form (hardcoded value is a bad design but best guess)
    offset = (offset / 2 ) +2;

    return blockLocation(scrollBar, p, offset);
  }

The above does not deal with border or insets of the arrow button which I've been unable to determine if these will impact the edge calculation or not. (hardcoded +2 value is a bad design but best guess for demostration)

There is other code in class that I've noticed to be abstract, which I've not been able to debug through. So maybe the code is not as above but else where.......

Once the correct value is provided, adding point to the screen location of the scrollBar in my tests provides the exact point to click. This deals with accessibility adjustments provided in an application for different scrollBar sizes.

---

votes (original issue): 0 watches (original issue): 0