United StatesChange Country, Oracle Worldwide Web Sites Communities I am a... I want to...
JDK-6336384 : ScrollBar does not show up correctly in 6.0

Details
Type:
Bug
Submit Date:
2005-10-13
Status:
Resolved
Updated Date:
2011-01-19
Project Name:
JDK
Resolved Date:
2006-02-07
Component:
client-libs
OS:
windows_xp
Sub-Component:
java.awt
CPU:
x86
Priority:
P3
Resolution:
Fixed
Affected Versions:
1.4.2_08,6
Fixed Versions:

Related Reports
Backport:
Backport:

Sub Tasks

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
WORK AROUND

Add items to the list after the peer creation
                                     
2006-01-16
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));
  }
                                     
2006-01-16
EVALUATION

suggested fix is low-risk so should be fixed in mustang
                                     
2005-10-27
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.
                                     
2005-10-19
EVALUATION

This test is all AWT code. Re-assigning.
                                     
2005-10-18



Hardware and Software, Engineered to Work Together