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.
Summary: | Setting BoxLayout on an awt Dialog generates exception after changing dialog class to JDialog | ||
---|---|---|---|
Product: | guibuilder | Reporter: | sandi_ro <sandi_ro> |
Component: | Code | Assignee: | issues@guibuilder <issues> |
Status: | RESOLVED INVALID | ||
Severity: | blocker | ||
Priority: | P3 | ||
Version: | 5.x | ||
Hardware: | PC | ||
OS: | Windows XP | ||
Issue Type: | DEFECT | Exception Reporter: |
Description
sandi_ro
2007-05-10 11:27:24 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? 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. 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 |