I am a 2 years advanced Borland Delphi user. I've been working with Object Oriented systems on Delphi from architecture
to  visual component creation. I am also a 2 years Java developer (EAI applications) in dispair looking for a chance to
finally get freed of Delphi and spread the World the news.

On NetBeans 6.1 I really feel like I almost got it! I have started using the component bindings and got very excited!
However, all my intusiasm got killed by the missing of one thing: form inheritance.
Delphi work is completely based on form inheritance and you can actually build your entire application from base forms,
like data listing and simple or master/detail data entries/updates.

Of course we can make it using NetBeans. It's nothing what an XML can't do by just configuring specialities of each
form. But it's absolutelly not what we need. We are looking for drag'n drop and visual form editing WITH form inheritance!

I speak english fluently and am able to speak to someone using skype and VNC or Netmeeting, and maybe record something
showing exactly what I'm talking about. I would be very, very glad to help with it!

Oh, and Don't tell me about that "Add as template" thing because that's not what I'm talking about. 
I'm talking about creating your form and making a new one VISUALLY extending that! Of course we can go ahead and edit
the source code to manually make the inheritance, but we NEED the components from the inherited form to be VISIBLE and
the public/protected components avaliable to be changed.

I really want to come to Delphi teaching schools and tell: let's Delphi finish it's dying! Come on to Java and NetBeans!

Thanks for offering help.

We need the inheritance support is limited, e.g. described here:
http://wiki.netbeans.org/wiki/view/FaqFormExtendingForms

The main limitation is that you only see the "container delegate" in the extending form - which is empty. You see all 
only in runtime. Second, it is not possible to change components (their properties) of the super class - even if they 
were visible in the extending form, they are not accessible (private fields declared in the base class). Third, it is 
not possible to add/remove components to/from non-empty containers defined in the super class - i.e. changing layout in 
the extending class, at least not for some layout managers (GroupLayout, GridBagLayout, BorderLayout).

All limitations could be dealt with somehow. What we need now is a specification - 1) how it should work for the user, 
2) how the underlying java classes (java code) would look like. Could you help with that? E.g. try to describe how 
would yu want to create a base form, how its code could look like (component fields protected modifier?), how would you 
like to define an extending form, see it in the designer and what to be able to change. Perhaps some more UI like 
navigation to the base form class - if you want to quickly change the base form itself instead of overiding it in the 
subclass. Etc. For all of that, it would be nice if you could e.g. record a video, or just describe how it looks like 
in Delphi and how it works under cover (I guess it is not based on class inheritance but done specially in the resource 
files somehow).

Having the specification would be a good leap forward...

Ok,
I will record a Delphi video and write some basic spec and make it avaliable online somehow.

Please, keep this a top priority enhancement because it is the one of the most useful things of a great RAD tool. This
is what made the mind of those who has chosen Delphi instead of Visual Basic on their times and is what I need to put
NetBeans on the road for new students.

I am going to do a more complex document but I can bring now a very important thing on Delphi: the recursive resource
file loading.

Let's suppose we have two forms BaseForm and ChildForm. BaseForm has a JLabel, a JText and a JButton, which basically
reads from the JText and prints out "Hello " + jtext.getText(). The resource file for this form has information for both
three component labels, positions, sizes and everything else. Now, create a new form inheriting from that one and do
nothing. What will we have on resource file for that child? Nothing. Now, change the button size; we will have only the
button size information on the resource XML. Change the caption of it; we have button size and caption information on
the resource XML.

The IDE must design the form on the screen recursivelly loading the resource files from the class inheritance. We can
find the resource file for the ChildForm during design time can't we? So we must find the resource file for the
this.getClass().getSuperClass().geSuperClass().... and so on.

This is exactly what happens on Delphi. The IDE designs all form components on the screen by loading the information
stored on the .dfm (Delphi Form) of all super classes before, overwriting it according they are changing during read. If
I create a button with size 10 on base class, change it on it's child to 30 and change on deeper child to 40, it will
appear as 40 at deeper, 30 at child and 10 at base.  If I do nothing on the button at the child class, it will show up
exactly like the base defines and as 40 size on deeper class.

This also answers like the child class changes the properties of the base class. We can't, for example, remove the
button on child class or change it's name; but we can make it invisible.

In fact, I believe this recursive resource loading answers a lot of questions related to the designer.
I will start writing the spec this weekend and let you guys know.

Thanks for describing how the resources inheritance works in Delphi. It makes sense, useful to know... In Java the
principle is similar, however there is a significant difference in that the forms are not constructed from resources but
they are java classes - so there must be java code defining the UI and doing all the changes in all the classes in the
inheritance chain. Resources (.form files) are only used by the GUI builder, not in runtime.

Just for illustration, the code in a subclass can do nothing (then the form looks same as the superclass), or change
something - e.g. a property or size of a component. For that the subclass must have access to the components of the
superclass. This could mean an extensible form needs to have protected fields for components (neither private, nor
local) so the subclasses can access them. And the GUI builder must be able to find and use the .form file for the
superclass to determine what the available components are and if they can be changed. (Right now the GUI builder knows
nothing about the base form - it's just an instance of a class that the designed form extends.)

Seems doable and rather straightforward for properties changes, however it would be more complicated with layout changes
(whatever change in size, position or number of components may require entire layout for a container to be rebuilt - for
some layout managers). But lets figure out first what needs to be done from a user's point of view.

Looking forward to your specification.

Right. I'm still working on that and trying to figure out the relation between the layouts.

I see that we can change the visibility of the components on the properties pane, and that can be useful if want to
prevent some components of the base form to be changed. A place to set the default visibility of the components would be
fine concerning that.

I didn't realize that the .form aren't used at runtime. But that doesn't change the idea to load the parent's .form file
as of the child. If that's at run time or design time, it doesn't matter.

Thanks for keep this on :)

*** Bug 158929 has been marked as a duplicate of this bug. ***

Changing priority. Not Critical.

Made a small improvement in this area for 7.4:
http://hg.netbeans.org/jet-main/rev/b56f31312585

Addressed the following limitation:
"The main limitation is that you only see the "container delegate" in the extending form - which is empty. You see all only in runtime."
Now when extending an JFrame or JDialog, its entire JRootPane is moved to the designer so everything from the superclass window should be visible. Of course in the subclass still can only design layout of the container delegate (plus set the properties of the base class bean).

Created attachment 134038 [details]
zipped NetBeans project illustrating how to extend a dialog in GUI builder