Java Reference
In-Depth Information
final JFrame frame = new JFrame("ACME Currency Converter");
frame.setContentPane(acmeGui.mainPanel);
acmeGui.quitButton.addActionListener(new ActionListener() {
public void actionPerformed(ActionEvent e) {
frame.dispose();
}
});
frame.pack();
frame.setResizable(false);
frame.setDefaultCloseOperation(JFrame.DISPOSE_ON_CLOSE);
frame.show();
}
You may notice that both the
mainPanel
and the
quitButton
fields are
referenced from this lifecycle code, and that this code doesn't necessarily
have to reside in the same class. This means external classes may need to
reference some of your components—those involved with the lifecycle of
the
GUI
. In that case, you have the option of making
mainPanel
and
quitButton
nonprivate fields, or you can implement getters as a way of
providing references.
TIP
10.7 Building and running your form
The
XML
-formatted .form file is the output of working with the
GUI
Designer,
but that
XML
file can't be compiled the way Java is. During the build process, that
file is read by
IDEA
, parsed and processed into a valid Java file, and then com-
piled into byte code like the rest of your source. That parsing and processing
stage must take into account that your form is bound to another Java class and
that the functionality of how the form should act is defined there. By making the
design of the forms more efficient, the process of how they're eventually con-
verted to byte code became necessarily more complex.
Luckily, most of this complexity is hidden from you and dealt with in the inner
workings of the
IDE
. By default, the passage from the
WYSIWYG
Fo r m Wo r k s p a c e
to a working, testable application is handled seamlessly with a single command. If
you're using
IDEA
to run build scripts, there's no change in process:
Build | Make
Project
(or
Ctrl+F9
) or even
Build | Make Module
processes your form files.
Once built, the classes can be run and tested just like any other classes.