How to create a Java GUI program

To get to the source code of the frame we have created so far select the frame in the tree and press the Generate View Java Code button from the toolbar. I assume the Name property of the frame is still set to myJFrame. So activate the popup menu on the source code panel and save the code as MyJFrame.java.

Be sure the SpeedJG.jar is visible on your CLASSPATH, compile the file, execute it, and you will have the same result as seen before by checking the frame.

Overwrite Dialog

Hint When exporting the generated source code yet another time into the same file a dialog pops up and asks you to overwrite it. By default SpeedJG only overwrites the previously generated code lines of the GUI class (or the Controller class when generating the controller code). Thus if you modify the layout of your GUI with SpeedJG and re-generate the code, your individually added code lines in your main class handling the GUI access (or controller events) remain untouched and valid.

Now there are some words to be said about the necessity of the code line
import speed.jg.*;
residing in the generated code:

  1. As you can see the code also contains a class named MyJFrameGUI, and this class extends another class named GUIObject. The latter is located in the SpeedJG.jar in a package named speed.jg. This is because it is used both by the GUI builder and the code it generates.
    So in case of sharing your programs generated with this tool, do you need to share the SpeedJG.jar too? Not at all! You can also share only the GUIObject.java file with your code.
    If you use the XML features (dynamical loading of GUI objects) of this tool - I'll show you later how this works - you must also share the SpeedJG.jar file.
  2. The main task of the GUIObject class is to store the different Components in a Hashtable and serve them later on. Further tasks are to load images and other resources from the CLASSPATH, serve popup menu controllers and calculate the size of Components with respect to their containers.

Are we able now to comment out the line
import speed.jg.*;
and use the locally stored GUIObject.java? Yes and no!

Yes, because we used some images out of the SpeedJG.jar. Therefore it is necessary in this example to have this .jar file on our CLASSPATH.

No, because SpeedJG borrowed these images from the Java look and feel Graphics Repository
jlfgr-1_0.jar
If you have this .jar file at your fingertips you can comment out the
import speed.jg.*;
line and put the GUIObject.java and the jlfgr-1_0.jar on your CLASSPATH.

The next task on our source code discourse will be how to generate the controller code with the event listeners. So go back into the GUI builder tool, select the frame in the tree and press the toolbar button Generate Controller Java Code.

Controller Code Dialog

Be sure you have activated the by default suggested listeners in the upcoming dialog. After confirming by pressing OK you will see the code in the source code tab. The name of the class this code belongs to is the name taken over from the Component we generated it for, plus either the extension Controller if we have more than one listener or Listener if we have only one.

So save this code as MyJFrameController.java.

Hint In this context it has to be mentioned that the selections you made will be stored within the XML structure of the respective component. Thus if you generate the controller code the next time you will get exactly the same selections you made before.

If you generate the controller code for the first time, you will get the default Listeners presented; and if you want to come back to the default listeners at a later date, Deselect all listeners, continue with OK and invoke this dialog again.

As from now there are two different possibilities to activate the controller code.

The first alternative is to simply uncomment the generated code line within our main class MyJFrame as shown below and modify the event-stubs within the MyJFrameController class. But when generating the controller code the next time, the changes you made within the controller class will be overwritten anyway, because the stubs residing there belong to the generated code class! 

public class MyJFrame
{
  public MyJFrame()
  { GUIObject gui = new MyJFrameGUI();
    MyJFrameController controller = new MyJFrameController(gui);
    JFrame frame = (JFrame) gui.getComponent("myJFrame");
    frame.show();
  }
...

The second and anyway better solution is to regard our MyJFrameController class as a Swing Adapter class that is tailored to our application, and let the MyJFrame class extend the controller. 

public class MyJFrame extends MyJFrameController
{
  public MyJFrame()
  { super(new MyJFrameGUI());
    myJFrame.show();
  }
...

Thus we get a first class Model-View-Controller separation whereas

  • all components are accessible from within our main class, and
  • the altered code lines within this (MyJFrame) class remain unchanged when generating new view or controller code.
SpeedJG MVC