![]() ![]() 16 July 2001 ![]() |
![]() |
Into Java, Part 18
Last time I promised you an overview of Java GUI stuff. In the past
we have used menus, buttons and a few more. Java offers you an extensive bunch of GUI stuff ready for use. Most
of them you can twist and tune to your needs, although it is not that easy all of the time. This time we will
use some of the most oft used items. |
Admittedly the bottom idea is borrowed from Core Java 2, Volume
1 by Horstmann&Cornell, but their OptionDialogTest does not offer all of the option panes, and I wanted
to use most of the GUI tools developers are used to seeing. Hence, this is a completely new application.
As you can see, we will make use of radio buttons, check boxes,
text input fields, a combo box and a selection list. All of these are heavily used in most applications. Unfortunately,
this column would grow into a booklet if I covered every aspect of these items, so I will only briefly show you
one or two ways to use them.
|
In the source code you will see that quite a few variables (objects)
are declared as instance variables. They are declard this way since they must be available later in the code.
Otherwise it is preferred to only declare them locally and so reduce the variable list.
The first line here shows how we create a ButtonGroup. That seems
confusing, until we realize that most clickable items are considered buttons, inheriting from jawax.swing.AbstractButton.
It is also possible to add other items than JRadioButtons to such a group.
Nevertheless, we will create a group that will assure that only
one of the JRadioButtons added to this group will be selected. We continue creating JRadioButtons one at a time
and add these to the group. We only show two of the radio buttons here. (The n seen here is only a Box to hold
the items.)
We add an actionListener, since we will change some information
on the application's panels depending on which radio button is selected. As usual we have a method, actionPerformed,
that takes care of the events resulting from selecting radio buttons issuing several if/else if-clauses.
The actionCommand is used when we would like to find out which
radio button is selected from a group. Note that if we would like to get the actionCommand, then we must add an
actionCommand. That differs from JButton were the button text is the command if a command is not explicitly set.
|
We ask the group for its selection which is a somewhat cumbersome
way to get the item that is selected. Once we have this item we ask for its actionCommand, the string we set before.
It will not become more complex than this. I have used a vertical
box, but any layout is possible. The button group is a question of code, not layout. Naturally, most users will
be surprised if they find the radio buttons spread about rather than together.
In conclusion, radio buttons are very useful when you look for
a visible GUI item, and only one choice is permitted at a time. They are grouped together.
|
When we want to control if a check box is selected we can ask them
one after another, as
stringCheck.isSelected()
within several if/if else-clauses. In the source code you can find
examples of this in the method getMessage.
|
|
|
|
|
So far we have seen the most often used GUI tools, and you can
make the choice yourself. There are many more to study, but for this I'll recommed you read Sun's
Java Tutorial on GUI Components. The source code ties them together on six panes where you can make your selections
to get the option pane you wish.
All of these three have a basic constructor that takes only two
parameters, the parent and the message. Simple, is it not? The best thing about them is if you do not want to,
you do not need do any more than use this one. Although most of us would like to try something stronger once in
a while. When this is the case, we have to know a little about the other options to use.
They are:
The message type simply chooses an appropriate
default style of the pane. The three have default types, but you can pick one yourself. Then you use constants
held by the JOptionPane class:
JOptionPane.PLAIN_MESSAGE
JOptionPane.ERROR_MESSAGE
JOptionPane.INFORMATION_MESSAGE
JOptionPane.WARNING_MESSAGE
JOptionPane.QUESTION_MESSAGE
The option type determines the set of buttons
on the dialog pane. If the constants are not satisfactory you can create anything with the showOptionDialog choice.
JOptionPane.DEFAULT_OPTION
JOptionPane.YES_NO_OPTION
JOptionPane.YES_NO_CANCEL_OPTION
JOptionPane.OK_CANCEL_OPTION
You are free to use any icon of your choice. It
will then appear at the left of the dialog box. I have rarely used this option since the message type icons are
most useful.
The object array can hold most objects, but I will not dig into
that since it is more tricky than I like. If you need these, it is maybe better to use the JDialog class and make
a dialog of your own design instead.
So far you might want to study this table, and at the same time
run the enclosed application.
|
Somewhat after the middle of the file the method actionPerformed
begins. The first clause takes care of the "Show" button. Since each dialog type has its pros and cons
I had to take care of it in a special way, I only use the most complex type of each dialog type but feed them
with the true default values if you have not selected one.
After that button we take care of when you select another radio
button, that is another dialog type. That action causes a few labels to express if an option is required, optional
or N/A. Again the code can be shortened at the price of readability.
So far a bunch of small methods take care of parsing the different
options, whether they are selected or not. When looking at getMessage we can see a mishmash of objects added to
an object array. Recall that the message can consist of any kind of object, and an array of them too. The result?
Sometimes it does not look that nice (grin).
There is not much to say about the rest of the methods, they deliver
the selected value, or the equality to no value at all, that is as if we called a constructor with fewer parameters.
In fact, when you use the simple constructors they, behind the curtains, call the more complex ones with default
values or simply with null pointers until they reach the most complex one. Hence, they are all using the same
fundamental dialog, but they offer simpler ways to get to it.
Next time I will present threading in Java. Since an application
"hangs" when it is executing a lengthy task, it does not listen to mouse clicks nor exit itself, we
have to use at least one more thread to takes care of time consuming tasks. Threading is the answer, but is it
easily done? Are they safe? Next month you will get the answers. CU then.
Source code: ShowOptionDialog.java
and OptionPanel.java.
Previous Article |
|
Next Article |