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.
 
 
 
 
 
Search WWH ::




Custom Search