JDK-6336384 : ScrollBar does not show up correctly in 6.0
  • Type: Bug
  • Component: client-libs
  • Sub-Component: java.awt
  • Affected Version: 1.4.2_08,6
  • Priority: P3
  • Status: Resolved
  • Resolution: Fixed
  • OS: windows_xp
  • CPU: x86
  • Submitted: 2005-10-13
  • Updated: 2011-01-19
  • Resolved: 2006-02-07
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.
Other JDK 6
1.4.2_13Fixed 6 b71Fixed
Description
ScrollBar sometimes show up incorrectly.

REPRODUCE :
1) Compile the sttached .java files
2) Launch "java Frame1"
   You will see a whindows having "show Dialog" button.
3) Click "show Dialog"
   you will see a dialogue box having "close" button.
   You may not see scrollbar in the dialog at this step.
4) Click the "close" button.
5) Click "show Dialog" at step 3)
   You will see scroll bar in the dialog.

PROBLEM:
 The list in the dialogue does not have so many items(Row 1,2 ...6).
 Also, the dialogue is big enough to show all the items without
 scroll. So, scroll bar is not needed at step 5),(see expected-dialog.jpg) 
 but actually scroll bar shows up.(see actual-dialog.jpg) 

CONFIGURATION :
  JRE : 1.4.2_07/5.0u3/6.0b54
  OS  : WindowsXP(SP1, Japanese)
Comments
SUGGESTED FIX #sccs diffs -C WListPeer.java ------- WListPeer.java ------- *** /tmp/sccs.hUAh1F 2006-01-16 15:40:13.000000000 +0300 --- WListPeer.java 2006-01-16 15:38:09.000000000 +0300 *************** *** 108,113 **** --- 108,119 ---- fm = getFontMetrics( li.getFont() ); + // Fixed 6336384: setFont should be done before addItems + Font f = li.getFont(); + if (f != null) { + setFont(f); + } + // add any items that were already inserted in the target. int nitems = li.countItems(); if (nitems > 0) { #sccs diffs -C awt_List.cpp ------- awt_List.cpp ------- *** /tmp/sccs.Xu7udJ 2006-01-16 15:40:47.000000000 +0300 --- awt_List.cpp 2006-01-16 14:52:29.000000000 +0300 *************** *** 344,356 **** ::ReleaseDC(GetHWnd(), hDC); long h = tm.tmHeight + tm.tmExternalLeading; ! ! int nCount = (int)SendListMessage(LB_GETCOUNT); ! int i; ! for(i=0; i<nCount; i++) ! { ! VERIFY(SendListMessage(LB_SETITEMHEIGHT, i, MAKELPARAM(h, 0)) != LB_ERR); ! } VERIFY(::RedrawWindow(GetHWnd(), NULL, NULL, RDW_INVALIDATE |RDW_FRAME |RDW_ERASE)); } --- 344,351 ---- ::ReleaseDC(GetHWnd(), hDC); long h = tm.tmHeight + tm.tmExternalLeading; ! // Listbox is LBS_OWNERDRAWFIXED so the items have the same height ! VERIFY(SendListMessage(LB_SETITEMHEIGHT, 0, MAKELPARAM(h, 0)) != LB_ERR); VERIFY(::RedrawWindow(GetHWnd(), NULL, NULL, RDW_INVALIDATE |RDW_FRAME |RDW_ERASE)); }
16-01-2006
WORK AROUND Add items to the list after the peer creation
16-01-2006
EVALUATION suggested fix is low-risk so should be fixed in mustang
27-10-2005
EVALUATION The problem is related to peer initialization logic. Let's consider scenario if the items were inserted in the list before the peer is created (as the attached testcase). Order of initialization is following (see WListPeer,WComponentPeer): - addItems (which were added before the peer is created) - show - setFont (update height based on sun.awt.windows.WFontMetrics) According native system behaviour: the scrollbar is shown (nonclient area) though the list is big enough to show all items (will attach native application). To fix it it's enough to change order: place optional setFont before addItems. Since the listbox has the LBS_OWNERDRAWFIXED style (the items have the same height) we should sent message LB_SETITEMHEIGHT with zero index. Some notes: It's important that we implement default/non-default (depends on hwnd==NULL) processing WM_MEASUREITEM (we initially update the item height when the list is created using sun.font.FontDesignMetrics - this height is greater than sun.awt.windows.WFontMetrics - so the bug becomes visible). Why we choose FontDesignMetrics? This behaviour is questionably. Reproducible not always because default processing WM_MEASUREITEM doesn't modify item height.
19-10-2005
EVALUATION This test is all AWT code. Re-assigning.
18-10-2005