This Bugzilla instance is a read-only archive of historic NetBeans bug reports. To report a bug in NetBeans please follow the project's instructions for reporting issues.

Bug 103628 - Setting BoxLayout on an awt Dialog generates exception after changing dialog class to JDialog
Summary: Setting BoxLayout on an awt Dialog generates exception after changing dialog ...
Status: RESOLVED INVALID
Alias: None
Product: guibuilder
Classification: Unclassified
Component: Code (show other bugs)
Version: 5.x
Hardware: PC Windows XP
: P3 blocker (vote)
Assignee: issues@guibuilder
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2007-05-10 11:27 UTC by sandi_ro
Modified: 2007-08-06 10:01 UTC (History)
0 users

See Also:
Issue Type: DEFECT
Exception Reporter:

Attachments
Add an attachment (proposed patch, testcase, etc.)

Note You need to log in before you can comment on or make changes to this bug.
Description sandi_ro 2007-05-10 11:27:24 UTC 
Step 1:
Design the dialog with project configured for platform jdk 6.0.
On the dialog set a BoxLayout one will get folowing code in initComponents function:

setLayout(new javax.swing.BoxLayout(this, javax.swing.BoxLayout.Y_AXIS));

Step 2. 
Use project settings and move to Platform "Java HotSpot(TM) Client VM
1.5.0_06-b05" . 

now previous generated code will generate folowing exception:
Exception in thread "AWT-EventQueue-0" java.awt.AWTError: BoxLayout can't be shared
        at javax.swing.BoxLayout.checkContainer(BoxLayout.java:415)
        at javax.swing.BoxLayout.invalidateLayout(BoxLayout.java:202)
        at java.awt.Container.invalidate(Container.java:1417)
        at java.awt.Container.setLayout(Container.java:1376)
        at javax.swing.JDialog.setLayout(JDialog.java:612)


Step 3.
Open design view for dialog, set dialog layout to be NullLayout , then set back
to BoxLayout, now generated code in initComponents is different: 

getContentPane().setLayout(new javax.swing.BoxLayout(getContentPane(),
javax.swing.BoxLayout.Y_AXIS));

running again the dialog works with no exception.


Expected results:
Changing platform must keep same functionality of generated code. Or at least
the generated code shall work similar on all platforms.
Comment 1 Tomas Pavek 2007-08-03 15:44:42 UTC 
I can't reproduce this issue, I always get the code with getContentPane() generated for JDialog. No matter what JDK I
use for the project. Tried with NB 5.5 and current 6.0.

Are you able to reproduce it? Can you provide exact steps how to reproduce?
Comment 2 sandi_ro 2007-08-04 10:02:58 UTC 
I think it was mainly my type of use that generated this issue and I could not identify at the time of initial post to
identify the correct cause.
Therefore the issue may be closed safely if the use case shall not be supported.

I corrected the description and added more details about how to reproduce.

I reproduced in NB 5.5. The code generated for awt dialog is 

private void initComponents() {

        setLayout(new javax.swing.BoxLayout(this, javax.swing.BoxLayout.Y_AXIS));

        addWindowListener(new java.awt.event.WindowAdapter() {
            public void windowClosing(java.awt.event.WindowEvent evt) {
                closeDialog(evt);
            }
        });

        pack();
    }


The probem was because because I changed from awt dialog to swing dialog by editing source, 
The only hint of the problem was exception at run time and no other indication from NB.

Maybe a good idea will be to have an mechanism to change the dialog base class so that one can easy switch from awt
dialog to swing dialog and back.
 

Thanks.
sandi_ro.
Comment 3 Tomas Pavek 2007-08-06 10:01:49 UTC 
I see now. Obviously, Dialog and JDialog requires different code and the GUI builder has no chance to react if you just
change it in the code. Actually you can change the base class in the code - but you must then open the form in GUI
design and let it regenerate the code for the new container type. To force code regeneration do whatever change in the
form and save (e.g. change some color and undo the change). So I'm closing this issue as it is not a defect.

You are right we could have a special feature for changing the base class of the form which would regenerate the code
automatically. We could even have the possibility of changing the class of any component in the GUI form ("morphing") -
where changing the form class itself would just be a special case. If you think it would be useful, could you file such
feature request for us? Thanks