Colors, Logging, and Event Handling for Applets

This tech tip was originally a posting to the Imaging Experts blog site written by Alex Harm, Senior Software Engineer at Snowbound Software.

This tech tip describes how to work with colors, logging, and event handling for applets in a way that is easier to maintain.

For example, let’s say that you are given the task to develop a Java applet to bring up an empty window and then allow the user to change the background color of the window with a menu.

The user does the following:

Selects Menu>Color>Blue.
Changes the background to color “071aaa.”
Prints the string “Blue” in the Java console.
The user does the following:

Selects Menu>Color>Red.
Changes the background to color “ff1a00.”
Prints the string “Red” in the Java console.
Now, make the Frame class. The first step is to define constants for those colors. One way to do this is to use the java.awt.Color constructor that takes three integer values: red, green, and blue. If you wanted to display an HTML color such as “071aaa,” you would have to translate the HTML hex string to the three integers. You would use Photoshop or a color web site to do this.

Another way to do this is to directly pass the hex value to the Color constructor that takes in a single integer value. For example, all you have to do is pass in an integer in hex format like the following:

Private static final Color BLUE_COLOR = new Color(0x071aaa);

This is easier than translating to RGB. The reason to use a static Color constant is so that you don’t have to reconstruct a new Color object every time the menu item is selected.

Here is an example of the ShortcutFrame code:

public class ShortcutFrame extends Frame

{

private static final Color RED_COLOR = new Color (0xff1a00);

private static final Color BLUE_COLOR = new Color (0x071aaa);

MenuItem miBlue;

MenuItem miRed;

public ShortcutFrame(Applet parentApplet)

{

MenuBar menuBar = new MenuBar();

Menu colorMenu = new Menu("Color");

miBlue = new MenuItem("Blue");

miBlue.addActionListener(new ActionListener()

{

public void actionPerformed(ActionEvent e)

{

performCommandBlue();

};

});

colorMenu.add(miBlue);

miRed = new MenuItem("Red");

miRed.addActionListener(new ActionListener()

{

public void actionPerformed(ActionEvent e)

{

performCommandRed();

};

});

colorMenu.add(miRed);

menuBar.add((colorMenu));

setMenuBar(menuBar);

}

private void performCommandRed()

{

setBackground (RED_COLOR);

log ("Red");

}

private void performCommandBlue()

{

setBackground (BLUE_COLOR);

log ("Blue");

}

public void log (String output)

{

System.out.println (output);

}

}

Notes:

Use “anonymous inner classes” to perform the action listening for the menus. The old paradigm is to have one global listener for all of their buttons and menu items. This results in one pretty ugly actionPerformed() method with a whole bunch of if/elses. The inner-classes allow one listener per UI element with no more if/else trees. These anonymous classes will show up as ShortcutFrame$1.class and ShortcutFrame$2.class at compile time.
Within the anonymous listener classes, do not perform the actual menu commands. Simply dispatch a method call which does the actual work, i.e. performCommandBlue. This makes the anonymous listener classes a lot cleaner, and also allows these commands to be called by keyboard shortcuts.
Do not call System.out.println directly in the performCommand methods. Instead, call a log method which does the printing. This way, later on, when you want to redirect the output somewhere else, you only have one place to change this. Also, if you want to turn off printing, you only have one line to comment out.

Category:

Online Demo