Books
in black and white
Main menu
Share a book About us Home
Books
Biology Business Chemistry Computers Culture Economics Fiction Games Guide History Management Mathematical Medicine Mental Fitnes Physics Psychology Scince Sport Technics
Ads

More Java Pitfalls Share Reactor - Daconta M,C.

Daconta M,C. More Java Pitfalls Share Reactor - Wiley publishing, 2003. - 476 p.
ISBN: 0-471-23751-5
Download (direct link): morejavapitfallssharereactor2003.pdf
Previous << 1 .. 43 44 45 46 47 48 < 49 > 50 51 52 53 54 55 .. 166 >> Next

If you do use the Singleton design pattern, be sure to implement your Singleton classes correctly—use a private constructor, and synchronize methods that need to be synchronized, looking at the code skeletons in Listing 15.1 and 15.2. Finally, again, watch your baseline! Poor practices, such as using Singletons as global variables, as well as the evolution of your Singletons into non-Singletons, can cause problems that will keep you up too late at night.
122 Item 16
Item 16: When setSize() Won't Work5
Most developers stumble upon pitfalls sequentially, based on their experience level with Java. The setSize() pitfall usually presents itself shortly after Java developers begin serious GUI development, specifically when they try to set the size of their first newly created custom components. BadSetSize, as follows, creates a simple custom button that we want to size to 100 by 100 pixels. Here is the code to create our custom button:
class CustomButton extends Button {
public CustomButton(String title)
{
super(title);
setSize(100,100);
}
}
In the constructor, developers often mistakenly assume that they can use set-Size()(width, height) in the same way they do when sizing a frame. The problem arises when the developer hasn't yet gained the knowledge of the Abstract Windowing Toolkit's (AWT) inner workings to understand that this code will only work under certain situations. He or she has no idea that setSize() will fail to correctly size the component. For example, when we place our custom button in the frame with other components using a simple grid layout, we get the results in Figure 16.1. Our button is 66 by 23, not 100 by 100! What happened to our call to setSize() ? The method was executed, of course. However, it did not give the final word on the size of our component.
Listing 16.1 shows the source code for BadSetSize.java.
Figure 16.1 Run of BadSetSize.class.
5 This pitfall was first published by JavaWorld (www.javaworld.com) in the article "Steer clear of Java Pitfalls", September 2000 (http://www.javaworld.com/javaworld/jw-09-2000 /jw-0922-javatraps.html?) and is reprinted here with permission. The pitfall has been updated from reader feedback.
When setSize() Won't Work 123
01 package org.javapitfalls.item16;
02
03 import java.awt.*;
04 import java.awt.event.*;
05
06 class CustomButton extends Button
07 {
08 public CustomButton(String title)
09 {
10 super(title);
11 setSize(100,100);
12 }
13 }
14
15 public class BadSetSize extends Frame
16 {
17 TextArea status;
18
19 public BadSetSize()
20 {
21 super("Bad Set Size");
22
23 setLayout(new GridLayout(2,0,2,2));
24 Panel p = new Panel();
25 CustomButton button = new CustomButton("Press Me");
26 p.add(button);
27 add(p);
28 status = new TextArea(3, 50);
29 status.append("Button size before display: " + 2
button getSize() + "\n");
30 add(status);
31 addWindowListener(new WindowAdapter()
32 {
33 public void windowClosing(WindowEvent we)
34 { System.exit(1); }
35 });
36 setLocation(100,100);
37 pack();
38 setVisible(true);
39 status.append("Button size after display: " + 2
button getSize());
40 }
41
42 public static void main(String args [])
43 {
44 new BadSetSize();
45 }
46 }
Listing 16.1 BadSetSize.java
124 Item 16
Let's examine the correct approach to sizing a component. The key to understanding why our code failed is to recognize that after we create the component, the layout manager—called GridLayout—reshapes the component in accordance with its own rules. This presents us with several solutions. We could eliminate the layout manager by calling setLayout(null), but as the layout manager provides numerous benefits to our code, this is a poor remedy. If the user resizes the window, we still want to be able to automatically resize our user interface, which is the layout manager's chief benefit. Another alternative would be to call setSize() after the layout manager has completed its work. This only provides us with a quick fix: By calling repaint(), the size would change, yet again when the browser is resized. That leaves us with only one real option: Work with the layout manager only to resize the component. Below we rewrite our custom component:
class CustomButton2 extends Button
{
public CustomButton2(String title)
{
super(title);
// setSize(100,100); - unnecessary
}
public Dimension getMinimumSize()
{ return new Dimension(100,100); }
public Dimension getPreferredSize()
{ return getMinimumSize(); }
}
Our custom component overrides the getMinimumSize() and getPreferred-Size() methods of the Component class to set the component size. The layout manager invokes these methods to determine how to size an individual component. Some layout managers will disregard these hints if their pattern calls for that. For example, if this button was placed in the center of a BorderLayout, the button would not be 100 by 100, but instead would stretch to fit the available center space. GridLayout will abide by these sizes and anchor the component in the center. The GoodSetSize class below uses the CustomButton2 class.
Previous << 1 .. 43 44 45 46 47 48 < 49 > 50 51 52 53 54 55 .. 166 >> Next