concept Canvas in category java

This is an excerpt from Manning's book Swt/Jface in Action: GUI Design with Eclipse 3.0. Login to get full access to this book.

Each type of control has a different default behavior for a given traversal key. For example, a TraverseEvent that results from a TRAVERSE_TAB_NEXT action will, by default, cause a traversal if the component is a radio button, but not if it’s a Canvas object. Therefore, by setting the doit field to TRUE, you override the default setting and allow the user to traverse. Setting the field to FALSE keeps the focus on the component.

As we mentioned in chapter 3, a Control object is any widget that has a counterpart in the underlying operating system. Instances of this class and its subclasses can be resized, traversed, and associated with events and graphics. Figure 7.1 shows some of the Control subclasses provided in SWT. Although of all them can contain graphics, only one class is particularly suited for GC objects: Canvas, shown at the bottom of figure 7.1. This class not only provides the containment property of a Composite, but also can be customized with a number of styles that determine how graphics are shown in its region.

Because of this, the code in this chapter will focus on creating images in Canvas objects. Since we have a means of creating graphics (the GC class) and a means of seeing them displayed (the Canvas class), let’s see how these classes work together.

Figure 7.2. Creating shapes on a Canvas using the graphic context

This example demonstrates two important concerns to keep in mind when you work with GCs. First, the program constructs its Canvas object before invoking the shell.open() method; it creates and uses the GC object afterward. This sequence is necessary since open() clears the Canvas display. This also means that graphic contexts must be created in the same class as the Shell object. Second, the program deallocates the GC object immediately after its last usage. Doing so frees up computer resources quickly without affecting the drawing process.

The concept of clipping is also important when you’re dealing with Paint-Events. Not only do these events fire whenever a Drawable object is covered by another window, but they also keep track of the area being obscured. That is, if a user covers part of a Canvas with a second window, the PaintEvent determines which section has been clipped and sets its x, y, height, and width fields according to the smallest rectangle that encloses the concealed region. This is necessary since repainting refreshes only this clipped region, not the entire object.

If multiple sections of a Control object are obscured, then by default, the object merges these sections into a single region and requests that it be repainted. However, if an application requires that separate requests be made for each concealed area, then the Control should be constructed with the NO_MERGE_PAINTS style. This is the first of the styles associated with the Composite class but specifically intended for Canvas objects. The rest of these styles are shown in table 7.3.

Table 7.3. Style options for Canvas objects

Style	Function
NO_MERGE_PAINTS	Keeps concurrent paint requests separate
NO_FOCUS	Specifies that Canvas can’t receive focus
NO_REDRAW_RESIZE	Specifies that Canvas doesn’t repaint itself if resized
NO_BACKGROUND	Specifies that Canvas has no default background color

Normally, when a user clicks a window, any keyboard input is directed to it. This property is called focus behavior, and you can remove it from a Canvas object by constructing the object with the NO_FOCUS style. Similarly, when a Canvas is resized, a PaintEvent is triggered by default and the display is repainted. You can change this default behavior by using the NO_REDRAW_RESIZE style. It’s important to note, though, that using this style may cause graphical artifacts during a resize operation.

Before a graphic context draws its images, its Canvas paints itself with the color of its shell, the default background color. These paint operations can cause screen flicker on certain displays. You can prevent this by using the NO_BACKGROUND style, which prevents the first painting. Without a background color, the graphic context must cover every pixel of the Canvas, or it will take the appearance of the screen behind the shell.