We Keep Coding

Java JFrame inheriting components from another JFrame

We have a form design, where many of the components are the same (navigating in a table, ResultSet etc.) The idea is to create a template, and every form would inherit from this template. Problem is: when I change the
public class TestForm extends javax.swing.JFrame { ...
to
public class TestForm extends Template { ...
the components in the Template form doesn't show up in the designer. Is there any solution to make them show up, and is it a good idea at all to do this?

There is no solution for you.
Even if you find away to show it in designer there will be not much use for it because you cant edit it. Netbeans know nothing about architecture of your Template. This mean it doesn't know how to reflect changes in desiner to changes in code.

Choosing between inheritance vs composition in swing GUIs [duplicate]

This question already has answers here:
Why shouldn't you extend JFrame and other components? [duplicate]
(5 answers)
Closed 7 years ago.
I was used to do java swing programming with netbeans drag and drop, and never really cared too much about the code it generated. Now I am in the process of learning to code GUIs without drag and drops.
The fundamental problem occurred to me was, whether the window I am going to make IS_A JFrame or HAS_A JFrame. i.e whether to use inheritance or composition.
if MyWindow is a JFrame
public class MyWindow extends JFrame{
}
if MyWindow has a JFrame
public class MyWindow{
private JFrame frame;
}
Both seems fine to me. But I guess there should be a right way to do it out of these two. What is the correct way, and why?

If you want your class to behave as a window, then, you should extend it from JFrame (at least in my opinion). To my knowledge, this is how you should go about it.
If on the other hand, you want a class which has access to a window then you would go with the second option. That being said, you would still, at some point need to initialize a class which extends from JFrame.
EDIT: The answer to the question does say that, however it also says that it depends on what you are after. If I am understanding the answer correctly (maybe others could comment on this), if you have a scenario where you need a frame to print a list to a table, you could have a class which extends Frame and provides a utility method which takes in a list and prints it to a table. Your logic would then instantiate this class instead of the actual JFrame and use it to show the data.
My approach is that usually, I have a class which extends JFrame and provides a series of methods which make printing data easy. I would then have another class, which links logic and view layers. This class will have a reference to the JFrame extending class.

JFrame child cannot see parent widgits

I have a JFrame application with some variables and a number of SWING widgets. In it I create an instance of another class and pass the JFrame to the child in the constructor. From the child, I can reference the variables, but not the widgets. Why?
// My JFrame
public class Prot2Prom extends JFrame {
// My Child
public Prot2Prom() {
super( "Protocol To PROM" );
Child child = new Child(this);
In the Child class my constructor does
Prot2Prom frame = null;
public Child(Prot2Prom gui) {
frame = gui;
}
The following works:
frame.<parent variable>=x;
The following does not:
frame.textArea.append("Hello");
The textArea cannot be resolved. There were all added with "new". Why can't I see them?

Some notes and recommendations:
This has nothing to do with "widgets" or Swing and all to do with visibility of variables. I'm guessing that textArea is not a public field of the Prot2Prom class.
If variables are public outside classes can "see" them, access them, modify them.
A possible solution is to in fact make the variables that you want other classes to see, public.
In general you really don't want to do this.
Instead much better is to give a class public methods that allow other classes to call and by doing so alter the original class's behavior. In other words, your Swing GUI classes should adhere to good OOPs principles just as any Java class should.
Later you'll want to read up on the MVC or Model, View, Control design pattern as a way of separating out behaviors of your code into separate logical entities, which can make your code much more flexible and powerful.
Edit 1
Regarding your comment:
The "widgets" are all created by WindowsBuilder Pro. I am trying to use the textArea to create my Eclipse Console for a stand alone (jar) application. How can I print to it from a class instantiated by the Frame?
You'll want to give the class that holds the textArea variable a public method:
public void appendTextAreaText(String text) {
textArea.append(text);
}
Then your other classes can append text to the JTextArea. Why is this important? One reason is that if the class that holds textArea will at some times not want to allow other classes the ability to append to this widget, it can have the logic to control this in the method. Thus it gives much more control over the widget to the class that holds it.
e.g.,
public void appendTextAreaText(String text) {
if (allowTextAreaAppend) { // a class boolean field
textArea.append(text);
}
}
As an aside, I also recommend that you put the code generation tool to the side and instead create your Swing GUI's by hand for a bit until you get a firm grasp of Swing and Java fundamentals. This will make your future use of the Swing code generation tool much better and productive.

The textArea cannot be resolved
This message indicates that there is no member class variable called textArea in Prot2Prom. This is possibly a typo. Perhaps the variable is called textarea or defined only locally in the constructor scope.
To work your class would look something like this
public class Prot2Prom extends JFrame {
JTextArea textArea = new JTextArea();
...
A better approach to updating text in a parent component is to create a method to Prot2Prom like so:
public void addText(String text) {
textArea.append(text);
}
This provides more control over how text is added to the JTextArea.

What's the rule of thumb regarding Swing component extension?

When dedicating a class to a particular Swing component, is it better to extend that particular component, or construct it internally and provide a reference?
public class Foo extends JComponent{
}
OR
public class Foo{
public JComponent getComponent(){
}
}
EDIT
This is what I mean by dedicating
public class Foo{
private static Foo INSTANCE;
public static Foo getInstance(){
if(INSTANCE == null){
INSTANCE = new Foo();
}
}
public void createAndShowComponent(){
//do stuff
}
}
Inside createAndShowComponent(), I create a JComponent with all its components and their respective listeners without exposing the internals of the component I just created.

+1 for Composition over extension. It makes the API much cleaner since you only expose what methods are important for your new component

I agree with jzd it all depends.
Technically speaking, if you are dealing with GUI in my opinion it is best to build components when you need them, by extending for example JComponent. This way you can simply reuse them.
Personally I would never use the 2nd option in my class. I would only have a class return another component only if there is a very good reason for doing so, e.g. to enable user to modify a button look in your complex calendar component.
For a very simple reason each component class should know what it has this component for, and it should control the view accordingly to what is happening. Thus you would have appropriate methods.

I would say extending it would be better. Being able to use all its properties and using it like it is that object makes it a lot simpler to use. Just my personal Opinion. Both ways are good.
If you are dedicating the entire class to it. Might as well make it that by inheritence.

If your object IS a component, than extend it. If not, then use composition.

It really depends on what you are doing. If you want to include your new class on a JPanel for example, you will need to extend the component. If your code can add the component to the correct place on the GUI, then you don't have to extend it.

I would say none of them. Swing components are very (very) rich and can be customized for visualisation (L&F) and behaviour (events) in any manner. Another point is to create a group of different components and lay them out in a JPanel.

How to use WindowBuilder to edit a JPanel in an inner class

I would like to use WindowBuilder in Eclipse to construct Swing GUIs. The JPanels I need to build will be inner classes in a non-GUI wrapper, like so:
public class MyWrapper extends MyBaseClass {
...
class MyPanel extends JPanel {
...
}
}
So my question is this: can I construct MyPanel using WindowBuilder? If so, how should I set it up?
If anyone is interested, the wrapper is an abstract base class which the plug-ins I am developing for my app must extend; deployment concerns mean that it's not really practical to put the GUIs in a separate JAR either so I pretty much have to do it this way.
My current workflow, which is awful, is to build the GUI in NetBeans and paste the entire generated class into Eclipse where I connect it up to the methods in my wrapper. I am very hopeful that WindowBuilder will let me work more reliably and efficiently if I can trick it into generating code in MyPanel, not MyWrapper.
Thanks

It isn't clear why the JPanel must be an inner class. In general, that is not a good idea (you will end up with multiple .class files either way). The JPanel should just be its own top-level class and referenced from your wrapper class (all of which can be in the same jar). WindowBuilder can easily be used to create/edit your JPanel subclasses (including ones originally created with NetBeans), but it will only do so for top-level classes. It won't allow you to create/edit an inner class like this (which is entirely intentional).