Documentation Contents
Java Platform, Standard Edition Troubleshooting Guide
Contents    Previous    Next

10.7 Focus Events

This section describes the following troubleshooting issues related to focus events.

10.7.1 How to Trace Focus Events

To troubleshoot a problem with focus, you can trace focus events. You can do it by adding a focus listener to the toolkit, as shown in Example 10-5.

The System.err stream is used here because it does not buffer the output.

Remember that the correct order of focus events is the following:

  • FOCUS_LOST on component losing focus

  • WINDOW_LOST_FOCUS on top-level losing focus

  • WINDOW_DEACTIVATED on top-level losing activation

  • WINDOW_ACTIVATED on top-level becoming active widow

  • WINDOW_GAINED_FOCUS on top-level becoming focused window

  • FOCUS_GAINED on component gaining focus

When focus is transferred between components inside the focused window, only FOCUS_LOST and FOCUS_GAINED events should be generated. When focus is transferred between owned windows of the same owner or between an owned window and its owner, then the following events should be generated:

  • FOCUS_LOST

  • WINDOW_LOST_FOCUS

  • WINDOW_GAINED_FOCUS

  • FOCUS_GAINED

Note: The events losing focus or activation should come first.

10.7.2 Native Focus System

Sometimes a problem may be caused by the native platform. To check this, investigate the native events that are related to focus. Make sure that the window you want to be focused gets activated and the component you want to focus receives the native focus event.

On the Windows platform, the native focus events are the following:

  • WM_ACTIVATE for a top-level. WPARAM is WA_ACTIVE when activating and WA_INACTIVE when deactivating.

  • WM_SETFOCUS and WM_KILLFOCUS for a component.

On the Windows platform, a concept of synthetic focus has been implemented. It means that a focus owner component only emulates its focusable state whereas real native focus is set to a focus proxy component. This component receives key and input method native messages and dispatches them to a focus owner. Prior to JDK7 a focus proxy component was a dedicated hidden child component inside a frame/dialog. In the latest JDK releases a frame/dialog itself serves as a focus proxy. Now it proxies focus not only for components in an owned window but for all child components as well. A simple window never receives native focus and relies on focus proxy of its owner. This mechanism is transparent for a user but should be taken into account when debugging.

On Oracle Solaris and Linux operating systems, XToolkit uses a focus model that allows AWT to manage focus itself. With this model the window manager does not directly set input focus on a top-level window, but instead it sends only the WM_TAKE_FOCUS client message to indicate that focus should be set. AWT then explicitly sets focus on the top-level window if it is allowed.

Note: The X server and some window managers may nevertheless send focus events to a window. However all such events are discarded by AWT.

AWT does not generate the hierarchical chains of focus events when a component inside a top-level gains focus. Moreover, the native window mapped to the component itself does not get any native focus event. On the Oracle Solaris and Linux platforms, as well as on the Windows platform, AWT uses the focus proxy mechanism. Therefore, focus on the component is set by synthesizing a focus event, whereas the invisible focus proxy has native focus.

A native window that is mapped to a Window object (not a Frame or Dialog object) has the override-redirect flag set. Thus the window manager does not notify the window about focus change. Focus is requested on the window only in response to a mouse click. This window will not receive native focus events at all. Therefore, you can trace only FocusIn or FocusOut events on a frame or dialog. Since the major processing of focus occurs at the Java level, debugging focus with XToolkit is simpler than with WToolkit.

10.7.3 Focus System in Java Plug-in

An applet is embedded in a browser as a child (though not a direct child) of an EmbeddedFrame. This is a special Frame that has the ability to communicate with the plugin. From the applet's perspective the EmbeddedFrame is a full top-level Frame.

Managing focus for an EmbeddedFrame requires special additional actions. When an applet first starts, the EmbeddedFrame does not get activated by default by the native system. The activation is performed by the plugin that triggers a special API provided by the EmbeddedFrame. When focus leaves the applet, the EmbeddedFrame is also deactivated in a synthesized manner.

10.7.4 Focus Models Supported by X Window Managers

The following focus models are supported by X window managers:

  • click-to-focus is a commonly used focus model. (For example, Microsoft Windows uses this model.)

  • focus-follows-mouse is a focus model in which focus goes to the window that the mouse hovers over.

The focus-follows-mouse model is not detected in XAWT in Java SE 7, and this causes problems for simple windows (objects of java.awt.Window class). Such windows have the override-redirect property, which means that they can be focused only when the mouse button is pressed, and not by hovering over the window. As a workaround, set MouseListener on the window and request focus on it when mouse crosses the window borders.

10.7.5 Miscellaneous Problems with Focus

This section describes some issues related to focus in AWT that can occur and suggests solutions.

Contents    Previous    Next

Oracle and/or its affiliates Copyright © 1993, 2019, Oracle and/or its affiliates. All rights reserved.
Contact Us