Object-Oriented Programming (Java), Unit 27

1. Object-Oriented Programming (Java), Unit 27 Kirk Scott

2. Focus • 27.1 Basic Focus • 27.2 More on Focus • 27.3 Assignment

3. Because the topic of focus is so important in graphical applications, it is given its own unit. • However, the unit is short because it is limited to a brief introduction to the topic and a simple example. • You can find much more information about focus in the Java Tutorial or in the Java Focus subsystem specifications. • There is a link to both of these sources of information from the documentation for the Component class in the Java API documentation.

4. One earlier example depended on the explicit use of focus—the example that was responsive to keystrokes. • The previous example programs that were responsive to mouse contained only one line that explicitly made use of focus. • It was necessary to make the panel focusable. • However, focus is a broader topic.

5. Going back to ClickCup, for example, that application contained a panel, which contained rectangles representing cups. • The panel also contained a mouse listener. • When the mouse was clicked over the panel, this event was passed to the application. • The mouse listener contained code to determine whether the click occurred inside one of the rectangles representing the cups.

6. When the application was running, the whole panel was active or responsive. • It would be possible to think of the panel as having the focus for the application. • Applications containing system supplied components help expand on this idea.

7. Take the most recent program, MiscLabel, for example. • There are no mouse listeners for either the overall panel in the application or the sub-panels that components are added to. • This program contains text fields which have their own listeners.

8. When the mouse is clicked over any one of the text fields, the cursor appears in that field and it is possible to type text into it. • When the cursor appears in a text field, that field has focus. • MiscLabel also has a button. • When the mouse is clicked over the button, the button receives the focus.

9. Because text fields and buttons are system supplied components, the system takes care of focus for them. • The focus system is also related to the handling of key events and associating them with components in an application. • The ClickKey example made simple use of key events.

10. The whole panel of the application was responsive to the clicked keys. • The call to setFocusable(true) was made in the panel class’s constructor • There was a listener that took certain actions depending on which cup was active and which key was clicked. • However, the focus in the application never changed.

11. Only one component in an application at a time can have the focus. • It is possible to traverse the focusable components of an application by hitting the TAB key as well as clicking on them with the mouse. • The components can be traversed in reverse order by using the combination shift+TAB.

12. You may already be familiar with this from using Windows based applications with multiple buttons. • Suppose you don’t have a mouse or the mouse is inactive. • You can tab from one button to the next causing each one in turn to have the focus. • Then the button can be selected by hitting the enter key or the space bar.

13. If an application has a text area, it is possible to enter a TAB as a character in the area. • Instead of using TAB to traverse to the next component, it is possible to use the key combination CTRL+TAB.

14. MiscFocus • In addition to the default focus behavior, it is possible to write specific focus behavior into application code. • The MiscFocus example illustrates this. • It is written so that when a new value is entered in one of the text fields the cursor moves to the other text field.

15. In this application each register has an instance variable holding a reference to the other register, which should receive the focus next. • This instance variable is set to the other register when each register is being constructed. • There is no basic change in the appearance of the application. • It’s not easy to see, but the screenshot does show the cursor in the text field which currently has focus.

17. In MiscFocus, the register objects have references to each other. • This could be indicated in a UML diagram by putting a “has-a” aggregation link from the register class to itself. • No diagram is given because this is only a minor change visually, and what it means can only be understood by referring to written explanations such as this paragraph anyway.

18. The code at the beginning of the MiscFocusPanel class follows. • The panel has two registers, registerA and registerB. • At the beginning of the class constructor the two registers are constructed and they are passed references to each other.

19. class MiscFocusPanel extends JPanel • { • private MiscFocusRegisterregisterA; • private MiscFocusRegisterregisterB; • public MiscFocusPanel() • { • registerA = new MiscFocusRegister("11110000"); • registerB = new MiscFocusRegister("00001111"); • registerA.setRegisterToPassFocusTo(registerB); • registerB.setRegisterToPassFocusTo(registerA);

20. The code at the beginning of the MiscFocusRegister class follows. • Each register has these instance variables: registerByte, myField, and registerToPassFocusTo.

21. class MiscFocusRegister • { • private MiscFocusByteregisterByte; • private JTextFieldmyField; • private MiscFocusRegisterregisterToPassFocusTo;

22. The getMyField() method follows. • It is called in the actionPerformed() method of the text field listener.

23. public JTextFieldgetMyField() • { • return myField; • }

24. The setRegisterToPassFocusTo() method which is called in the panel constructor follows.

25. public void setRegisterToPassFocusTo(MiscFocusRegisterregisterIn) • { • registerToPassFocusTo = registerIn; • }

26. The code for the TextFieldListener, an inner class, follows. • The last line of code in the actionPerformed() method accomplishes the switch of focus between one register and the other.

27. private class TextFieldListener implements ActionListener • { • public void actionPerformed(ActionEvent event) • { • String inputString = myField.getText(); • registerByte.setByteToThisString(inputString); • registerToPassFocusTo.getMyField().requestFocusInWindow(); • } • }

28. In the listener attached to one register’s text field you have access to the reference to the other register. • You then call the get method to obtain a reference to its field. • Notice that technically this is a violation of encapsulation.

29. The method requestFocusInWindow() is called on the field. • That method is inherited from the JComponent class. • It is that call which transfers the focus from one field to the other.

30. 27.2 More on Focus • Focus is an extensive topic. • This section mentions a few aspects of focus more advanced than what was illustrated by MiscFocus. • By noting some ideas and classes, this section should serve as an entry into the Java API documentation and the tutorials on this topic. • More complete information on how to use these aspects of Java is available there.

31. There are many different scenarios where code might affect focus in an application. • It might be desirable to create a non-system supplied component which is capable of receiving focus. • It might be desirable to override the default focus behavior of an application, such as the traversal order of components.

32. It might be desirable to introduce new behavior, in addition to the default. • It might be desirable to have the application respond to keys other than the defaults. • It might be desirable to write special purpose code so that the application exhibits similar behavior across platforms.

33. The tutorial points out that in Microsoft Windows, the frontmost window in an application has focus by default • In Solaris the window which the mouse pointer is over has focus. • Code could be written so that an application followed one of these two conventions consistently.

34. A fuller understanding of focus depends on the ideas of containers and layouts. • Any Java component which is a container serves as the root of a traversal cycle for all of its focusable components. • A given application may have more than one container, so at an upper level it’s possible to cycle among the containers.

35. Each container may have a layout. • Recall that the appearance of the components in a layout depends on the order in which they were added to the container. • In the same way, the default traversal order for the components in the container corresponds to the order in which the components were added to the container.

36. In the MiscFocus example there is just one overall container, the frame, which has a content pane which contains the overall panel for the application. • This panel contains multiple components, each in a panel of its own. • Traversal occurs between these components in their individual panels according to the GridLayout of the overall panel.

37. In order for a programmer-written component to be focusable, it has to have a visual representation and be enabled. • To make it focusable in code, this call is made: • component.setFocusable(true); • You may recall that this line of code appeared in the constructor of the ClickKeyPanel • setFocusable(true);

38. Referring back to the ClickKey example, in that case only the panel received keystrokes. • It would also be possible to write the code in such a way that each cup had its own listener, and when the cup had focus, the listener would cause it to respond to various keystrokes in various ways. • A future example, MiscAction, will explore this idea further.

39. If a change in the traversal order of the components of an application is desired, a simple, logical approach is to change the order in which components are added to their container. • It is also possible to remove a component from the traversal cycle by making it unable to receive focus. • That is accomplished with this call: • component.setFocusable(false);

40. In general, focus traversal depends on this class: LayoutFocusTraversalPolicy. • As you can see by the name, the traversal policy is associated with the layout. • To make major changes in focus traversal policy, it is possible to extend the FocusTraversalPolicy class, make an instance of this class, and then add it to the container with a call like this: • container.setFocusTraversalPolicy(instance of policy);

41. Just as a container has a layout, it can have a custom traversal policy associated with its layout, which overrides the default behavior described earlier. • It is also possible to change which keys in an application will cause traversal.

42. Focus and traversal can interact with the logic of a program. • For example, Java has an InputVerifier class. • This can be used to make sure that text entered into fields agrees with a predefined format. • For a component like a text field, the focus may be passed to another component when text is received due to pressing the enter key.

43. Input verification is triggered by the attempted change in focus, but if the input doesn’t agree with the specifications, the focus is not shifted. • The focus remains on the same field so that correct text can be entered. • In other words, the application won’t let you leave the text field until a correct value is entered. • You have probably encountered behavior like this in Web forms before.

44. When writing code that explicitly works with focus, it may be desirable to track the focus changes over multiple components. • That is, at various points you may want to get information on which component currently has focus. • There are three classes that are relevant to this. • An instance of the FocusListener class can inquire about focus.

45. The KeyBoardFocusManager class is the main class for focus handling. • It has API’s for inquiring about focus, for initiating focus changes, and for replacing default focus event dispatching with custom dispatching.

46. An instance of the PropertyChangeListener class can inquire about focus when applied to an instance of the KeyBoardFocusManager class for the application. • The property change listener can then be coded to take appropriate action based on the focus situation it finds.

47. The Java documentation lists eight concepts involved in the KeyBoardFocusManager class. • The general idea of most of them has been touched on empirically in the discussion above. • They are listed on the next overhead.

48. 1. The focus owner (a component). • 2. The permanent focus owner (a component). • 3. The focused Window (the frame or dialog which contains the focus owner component). • 4. The active Window (the frame or dialog which either has the focus or owns the frame or dialog with the focus). • 5. Focus traversal. • 6. Focus traversal cycle. • 7. Focus cycle root. • 8. Focus traversal policy.

49. The general model for focus traversal is based on a set of events which are defined in the WindowEvent and FocusEvent classes. • The model can be explained with a simple scenario: • Suppose an application has two windows, each containing a component.

50. Let AWindow contain AComponent and BWindow contain BComponent. • Suppose that AComponent currently has the focus and the user clicks on BComponent. • This is the full sequence of focus events which is generated and handled when this action is taken: