(^398) | Event-Driven Input and Output
If you want to clear the field so that it appears empty, you simply call setTextwith an
empty string:
inputField.setText("");
A call tosetTextimmediately changes the contents of the field on the screen. You donot
call the frame’ssetVisiblemethod again to update the field. In the last section, we saw how
a field can be given a default value by its constructor. Once a field has been created and shown
on the screen, it is often useful to be able to change its contents. For example, if the user en-
ters an erroneous value into a field, we might display an error message and set the contents
of the field to some value that shows the user how to type an input value correctly.
We previously mentioned the getTextmethod, which is also associated with JTextField.
It enables us to get the current value in the field as it appears on the screen. The getText
method returns a value of the class Stringthat holds a copy of the contents of the field. For
example, if we declare a Stringvariable called fieldContents, we can write
fieldContents = inputField.getText();
to store the characters currently contained in inputFieldinto fieldContents.
Note that we have not yet said anything about when or where to call the getTextmethod.
We have considered the steps of creating the field and taking data from it in isolation from
the rest of the application. In the following sections, we examine how these steps are related
to handling a button event that tells the application when the user is ready to have it look
at the data.
8.7 Reading Data in an Event Handler
Once a button fires its event, control transfers to the first statement in the event handler. But
what should the event handler do? In this case, the event is the user’s signal that some data
has been typed into a field and is now ready for processing. Because we have just been ex-
ploring the mechanics of getting the data, rather than solving an actual problem, we don’t
know what the data represents or what we should do with it.
Our discussion up to this point has put the cart before the horse. In solving a real problem,
we begin by identifying the input data and specifying what should happen to it. Then we de-
sign the user interface to enable the user to enter the data and generate the events that cause
the code to process it. Let’s once again look at a trivial problem that we can use to illustrate the
design process. Suppose the user should be able to enter a string and have it appear in a label
in the same frame when he or she has finished typing. Here is a definition of the problem:
Input: A string that the user enters
Output: The input string, displayed in a label
Processing: Copy the input string from the data entry field to the label
When does the code copy the input string to the label? We need an event to signal when
the user has finished typing. Let’s use a button called “Copy” to generate the event. What hap-