Issue 70683 and issue 72293 suggest to use "Set Default Layout" menu item for this.

For custom container the problem is solvable even without this option - as described in issue 80042 (or issue 88671).

A different problem is when plain JPanel is used in design and the user class is specified as custom container - then 
the user needs to be able to say explicitly not to set the layout.

Reading the crap I wrote, the last sentence should have been:

A different problem is when the user container class is specified via custom creation code while only plain JPanel is 
used in the design...

It's very disappointing that this simple enhancement hasn't been done for 6.0 
:-( 

It's very difficult to understand why custom panel isn't shown in the described conditions. 
I faced with the problem multiple times. Tt is easy to forgot about such constraint 
and face with it again and again. 

I'm facing this issue in NB 5.5: (i did not seem to have it in NB 5 ?)
we design a JPanel with some ui components and funct using gridbaglayout, then we try to create more detailed ones through inheritance, but the descendant 
resets the layout manager so all components are messed up. It has taken me quite some time to realize that NB insist on setting a layout manager. Right now 
the only solution I know is, once I'm satisfied with the descendant, delete(rename) the form and edit initComponents() with a third party editor. Is there a 
better way? (this is some 50K+ lines, 300+ files source I have inherited, so refactoring does not seem likely  ...).

To javierbds: Could you attach sample forms that demonstrate the problem? What you describe should work - the 
descendant form should either not act as a container if the base form contains some components; it should set layout 
only if the base form is empty (then it should not affect anything). Situation where the base form has subcomponents 
and the subclass form removes them should not happen.

The problem might be in that the descendant form is not able to use the base class (not compiled, or not a JavaBean) - 
thus using JPanel/JFrame instead as a fallback (i.e. an empty container). In this case you should either fix the base 
class, or eliminate the setLayout call by setting the layout to FlowLayout/BorderLayout (default JPanel/JFrame's 
layout).

But we'd need to have the forms to see what exactly you are doing. Thanks.

The problem was that I had made the form initialization code dependent on the initialization of some global resource, so when NB tried to create an instance 
it failed with NPE as the global resource was not available, so it failed back to being a JPanel. I was not aware of how NB created a 'design view' of an UI 
component. 

By the way, access to NB log file should be easier (messages.log), at least on OS X I could find no reference to it in help search (it shows info about servers 
logs ...)

Thanks tpavek

Besides the exception in constructor of the base class, the other problem is that the subclass uses the same container 
for its components that comes already filled with components from the base class. Such a container reuse between 
inherited forms (or in a container bean) is not supported, we require the container to be initially empty. We should 
decide whether/how we should deal with that. We could support form inheritance in a special way (by 
generating 'protected' fields in the superclass and then in the subclass look into the superclass' form to know what 
components are inherited and accessible). But building the container's layout on more places (in the base class and in 
subclasses) could be quite tricky.

*** Issue 158560 has been marked as a duplicate of this issue. ***

Some improvements made in:
http://hg.netbeans.org/jet-main/rev/1196c3966367

"Do not set the layout" can now be expressed by selecting the layout marked as default in the Set Layout menu (i.e. the user does not need to know which one it is for given container). In such case no setLayout code will be generated.

> This affects a custom container extension which the user doesn't want the
> layout set as they have already set the layout they need.

Also the GUI builder now will not try to set any layout (e.g. switch to Free Design mode) for custom containers with different layout than was in their Swing superclass. So custom containers with some preset layout will be added unchanged.

I think we can consider this fixed now.

As always Tomas...you are the man! I think this is a good improvement for the designer.