![]() |
|||
![]() ![]() |
![]() |
![]()
|
![]() |
Size PreferencesAWT components contain the trio of methods getPreferredSize, getMinimumSize, and getMaximumSize to aid layout managers when they are arranging containers. In these methods, the component is to determine the requested size based on its current state. For example, the JLabel class determines its preferred size based on its font and text that needs to be displayed. By default the JComponent class behaves the same as the AWT Component class for size calculations. However, JComponent adds the setPreferredSize, setMinimumSize, and setMaximumSize methods for setting the sizes. If one of the sizes has been explicitly set via one of these methods, the associated get method returns that size, rather than computing the size based on state. Thus the value specified in the set method takes precedence over a calculated value. After having learned from the AWT that hard-coding component sizes is bad and that the preferred technique is to dynamically determine size based on font, screen resolution, and so on, why has the JFC changed the rules? The truth of the matter is that the rules have not changed. Everything you have learned about dynamically determining a components size still applies. However, the JFC gives you the flexibility to alter the sizing behavior of a component that the layout manager will use. For example, you may want a certain label to always occupy at least the left 25 percent of a container, regardless of the text it contains. This functionality can be achieved easily by using the setMinumumSize method of the label. Also, some classes of components, such as a JViewPort, dont have natural minimum, maximum, or preferred sizes. You may want to set these sizes to achieve the desired layout of a container. After a size has been explicitly set by using one of the set methods, setting the size to null will restore default behavior. This allows size overriding to be turned on and off via any of the setter methods. Each of the three sizes is a bound property in the JComponent class. A complete list of bound properties defined in the JComponent class is presented in Table 3.1 later in this chapter. Keystroke HandlingThe JComponent class provides a wealth of keystroke handling functionality. These methods provide a much higher level interface than processing individual keystroke events in a subclass of JComponent. You are also able to set which action is executed for a keystroke that occurs in a JComponent without having to subclass the component. The registerKeyboardAction method is used to bind a KeyStroke to an ActionListener. When the KeyStroke is detected, the actionPerformed method of the ActionListener is called. Registering a keyboard action for a component enables keyboard events for that component. Internally, the JComponent class stores a Hashtable of registered keyboard actions as a client property. One of three conditions can be specified when binding the KeyStroke with the ActionListener. The first, WHEN_FOCUSED, requires that the KeyStroke event occur in the component when it has the keyboard focus for the action to be invoked. The second, WHEN_ANCESTOR_OF_FOCUSED_COMPONENT, will invoke the action if the component is the ancestor of the component with the focus or is itself the focus component. This condition is useful for registering keystroke actions on a dialog box for dialog box default behavior. For example, the Escape key could be mapped to the cancel action in the content pane of a JDialog instance. Then, when this key is typed in any JComponent in the dialog box, the cancel action would be invoked. The last condition, WHEN_IN_FOCUSED_WINDOW, will invoke the action if the component is in the same window as the component where the KeyStroke was entered. This is convenient when you do not want to register the keystrokes at the top of a containment hierarchy. The same effect can be achieved by having a cancel button that registers the close action to the escape KeyStroke with the WHEN_IN_FOCUSED_WINDOW condition. In this situation, when the escape key is pressed in any JComponent in the dialog box, the cancel buttons close action would be invoked. Lets look at an example of each of these cases. The first example, shown next, registers a keyboard action to the ageText JTextField component shown in Figure 3.2. This code will cause the textActionListeners actionPerformed method to be called whenever the Escape key is entered in the ageText component and only in the ageText component. ActionListener textActionListener = new ActionListener () { public void actionPerformed( ActionEvent event ) { System.out.println( textActionListener + event ); } }; ageText.registerKeyboardAction( textActionListener, KeyStroke.getKeyStroke( KeyEvent.VK_ESCAPE, 0 ), JComponent.WHEN_FOCUSED ); This code example introduces two new classes; KeyStroke and KeyEvent. The KeyStroke class is part of the JFC, and the KeyEvent class is part of the AWT. A complete discussion of the KeyEvent class is beyond the scope of this book. However, it is sufficient to say that the KeyEvent class contains virtual bindings for keystrokes. These are defined with constants defined in the class. Each virtual key constant begins with the VK_ preface. Using the constants defined in the KeyEvent class will ensure that your application is not dependent on a particular keystroke mapping. The previous example uses the VK_ESCAPE constant that, as its name implies, represents the Escape key.
|
![]() |
|