Bug ID: JDK-4690266 REGRESSION: Wizard Page does not move to the next page

Versions (Unresolved/Resolved/Fixed)

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
1.4.2 mantisFixed

The wizard made of Swing components does not move to the next wizard page
with 1.4.0fcs and 1.4.1beta-b12.

This application worked well with 1.3.1_03 and _03.
This is regression.

1. Reproduce

 1) Create the directory "wiz" and copy all the attached .java files.
 2) Compile the java file like "javac wiz\*.java"
 3) Invoke "java wiz.WizJ2CBMain"
    -> You will see the wizard page which has textfield and 5 buttons.
 4) Click the "Next(N) >" button.
   
 Here, the test program expect the wizard goes to the next page,
 but does not with 1.4.X.

2. Configration

  MPU: Pentium IV 1.4[GHz]
  MEM: 384[MB]
  OS : Windows 2000 (SP2, Japanese)
  JDK: 1.4.0fcs and 1.4.1-beta-b12
  
java version "1.4.0"
Java(TM) 2 Runtime Environment, Standard Edition (build 1.4.0-b92)
Java HotSpot(TM) Client VM (build 1.4.0-b92, mixed mode)

java version "1.4.1-beta"
Java(TM) 2 Runtime Environment, Standard Edition (build 1.4.1-beta-b12)
Java HotSpot(TM) Client VM (build 1.4.1-beta-b12, mixed mode)


3. Note

 - Because the first page and the second page lookes similar, it may
   difficult to check which page is currently displayed. 
   As for the 1st page, the "1stPage" label will displayed above the textfiled.
   2nd page, "2ndPage" as well.

 - Those sample code files include a lot of Japanese comments.
   If hard to read them, please delete those comment like
     sed -e 's/\/\/.*$//' original_file_name > redirect_file_name

2002-05-23
===============================================================================

CONVERTED DATA BugTraq+ Release Management Values COMMIT TO FIX: mantis FIXED IN: mantis INTEGRATED IN: mantis
24-08-2004
SUGGESTED FIX Name: osR10079 Date: 09/24/2002 See 4546123. ======================================================================
24-08-2004
EVALUATION This test case is using CardLayout to handle layout. It would appear they are maintaining the hidden/visible state of the components themselves and not calling into one of the CardLayout methods to adjust the card that is visible. In 1.3.1 CardLayout.layoutContainer would set the bounds of all visible components where as in 1.4 layoutContainer will force the current card to be visible and only adjust its bounds. As this appears to be purely an issue with CardLayout I am reassigning to awt. ###@###.### 2002-05-23 It sounds as though this is a problem in client code. We should investigate it for Mantis. ###@###.### 2002-05-28 Name: osR10079 Date: 09/04/2002 This is regression from fix for 4362381 (Once the remove button had press, next item from the list should show.) After this fix CardLayout uses its internal data only. But this data doesn't modified because in the test users don't use CardLayout API. Although that kind of usage is not very good, it's correct from API specification point of view and looks like we have to refix 4362381 to avoid this regression. ###@###.### 2002-09-04 ======================================================================
04-09-2002
WORK AROUND Use one of the CardLayout methods (show, next, first) to adjust the visible component vs adjusting the visibility directly. ###@###.### 2002-05-23
23-05-2002

Duplicate :	JDK-4890245 - CardLayout lays out cards visibly
Relates :	JDK-4546123 - CardLayout becomes unusable after deleting an element