Custom Component Creation

Suppose you need a component that behaves much like a JLabel, showing a line of text, except that the text appears in mirror-reversed form. No standard Swing component does this. When the component you need does not exist, you build one yourself. This article follows one such example, a class called MirrorText, and uses it to show three things: how a custom component is assembled, how its content is painted, and where a mistake would reveal itself.

The code in this example is best read as a traceable program. Treat it as a sequence of concrete operations, one after another, rather than as a finished description of a feature. As you read, keep asking which line is responsible for each thing you see on screen.

The MirrorText class is defined as a subclass of JPanel, and that single decision determines most of what the class inherits. It gets the panel's ability to be placed in a layout, its size handling, and its use of colors and fonts. The class then adds only what is specific to it: a constructor that receives the text to show, and a setText() method that replaces that text later. Everything else is already present because of the parent class.

Follow the life of one MirrorText object. The constructor receives the text to show and keeps it. Later, a call to setText() replaces that stored text with a new value. Notice that neither operation draws anything on screen by itself. The text only becomes visible when the component is painted, which is the subject of the next section.

Everything the user sees inside a custom component comes from one method: paintComponent(). MirrorText overrides this method to draw its text mirror-reversed, centered within the available area. Overriding means that the class supplies its own version of the method, and the drawing logic inside that version is what determines the visible result.

Centering is not guessed. The method uses information from a FontMetrics object, which describes how large the text will be when drawn in the current font. With that size known, the text can be positioned in the middle of the component rather than at an arbitrary spot.

Before reading on, ask yourself this: if paintComponent() can draw straight onto the visible area, why would a designer need anything in between? Hold on to that question. The answer is the mirror-reversal technique, and it depends on an intermediate image.

The text is first drawn onto this image in the ordinary way, exactly as if it were being drawn normally. Nothing about the text is reversed during this first step. Only afterwards is the finished image copied onto the visible component. The reversal happens in the copy, not in the drawing.

The figure shows a one-way movement. Text goes into the hidden image, and the image is then handed to the screen by a single drawing call. The component never draws the reversed text directly. It draws an image that was prepared earlier, and the copy operation is where the orientation of that image is changed.

The copy step is performed by one command. In it, OSC names the off-screen canvas, and width and height give the size of both the component and the off-screen canvas, which are the same size. The drawImage method, as used here, takes a destination rectangle followed by a source rectangle, each given by two corners.

A custom component has several places where its output can go wrong, and the pipeline above tells you where to look. Because the visible result is produced by a copy from an intermediate image, a mismatch between what you expect and what you see usually comes from one of three stages: the drawing into the off-screen canvas, the copy command, or the painting method that calls them.

The reversed output is most likely introduced at the drawImage call. The drawing into the canvas happens in normal orientation, so a reversed result that appears on screen points to the copy arguments first. This is why a mistake in the copy arguments is the first place to look when the output is wrong.