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 12719 - GandalfPersistenceManager NullPointerException when saving RADContainer objects
Summary: GandalfPersistenceManager NullPointerException when saving RADContainer objects
Status: VERIFIED FIXED
Alias: None
Product: guibuilder
Classification: Unclassified
Component: Code (show other bugs)
Version: 3.x
Hardware: PC Windows ME/2000
: P3 blocker (vote)
Assignee: issues@guibuilder
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2001-06-08 22:30 UTC by Adam Mlodzinski
Modified: 2001-07-20 20:39 UTC (History)
0 users

See Also:
Issue Type: TASK
Exception Reporter:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Adam Mlodzinski 2001-06-08 22:30:49 UTC
I have begun using RADContainer objects to store non-visual beans in my visual 
forms.  I had to add a section of code to JavaCodeGenerator.addInitCode in 
order to actually generate the code.  It seems to work well.
However, in order to get it to save changes to the form, I had to add a small 
fix to GandalfPersistenceManager.  I have not been able to isolate the cause, 
but have found a "patch" that avoids the problem.
The problem is in the first line of the saveConstraints method in GPM:

    private void saveConstraints(~~) {
      LayoutSupport laySup = component.getParentContainer().getLayoutSupport();
      if (laySup == null) return;

When I try to save a form with RADContainer objects, 
component.getParentContainer() returns null, which breaks this line.
The fix I added simply tests component.getParentContainer():

        RADVisualContainer parent = component.getParentContainer();
        if (parent != null)
           laySup = parent.getLayoutSupport();
        if (laySup==null) return;

The result is that if component.getParentContainer90 is null or 
component.getParentContainer().getLayoutSupport is null, then return - the same 
IMHO as the original, but with added error checking.  I suggest that this bit 
of code be added, if not for RADContainer support then simply for robustness.

btw, my fix for JavaCodeGenerator.addInitCode adds the following code 
segments.  I don't think that this should not impact the persistence manager.

Added at line 661 & 681:
     } //PENDING - adding to non-visual containers
      else if (comp instanceof RADContainer)
       generateNonVisualComponentAddCode(children[i],(RADContainer)
comp,initCodeWriter); }

Added elsewhere:
    private void generateNonVisualComponentAddCode(RADComponent comp,
     RADContainer container,Writer initCodeWriter) throws IOException{
        initCodeWriter.write("\n" + container.getName());
        initCodeWriter.write("." + container.getContainerGenName()); 
        initCodeWriter.write("add(");
        initCodeWriter.write(comp.getName());
        initCodeWriter.write(");\n");
    }
Comment 1 Tomas Pavek 2001-06-12 11:08:03 UTC
The reason why the RADContainer is not used in Form Editor is (probably) that 
it is unclear (for me at least) what it should be like. This is quite apparent 
with visual containers - they apply the AWT container/component hierarchy, but 
what is it "non-visual container"? There's no spec for it. It's not true that 
it is "just an object with some properties - no requirements other than getters 
and setters". At least, the container bean must have an "add" method - that's 
pretty special requirement. And how do you recognize that certain bean is non-
visual container? I think it is not possible to handle non-visual containers in 
general, only to create some special support for some kind of beans. Then there 
should probably be no RADContainer class, but the ComponentContainer interface 
should allow more extensibility - this is however not true in the current Form 
Editor.

I don't think this patch should be applied in the regular module code - at 
least the JavaCodeGenerator part. Maybe the RADContainer class was originally 
intended only for presentation (to group components suitably somehow), but not 
for code generation.
The change in GandalfPersistenceManager would not harm anything, so it could be 
applied.
Comment 2 Tomas Pavek 2001-06-12 17:36:54 UTC
The patch for GandalfPersistenceManager applied in dev trunk, see
GandalfPersistenceManager.java, revision 1.73.
Comment 3 Marian Mirilovic 2001-06-13 10:55:17 UTC
Adam,
could you verified this patch, please .

Thanx.
Comment 4 Marian Mirilovic 2001-06-18 16:22:09 UTC
verified in [nb_dev](212)
Comment 5 Adam Mlodzinski 2001-06-18 18:49:24 UTC
The patch for this issue has been applied.  Thanks guys.