JDK-4922092 : Focus is not restored to Swing components in ActiveX bridge
  • Type: Bug
  • Component: client-libs
  • Sub-Component: java.awt
  • Affected Version: 1.4.1,1.4.2,5.0
  • Priority: P2
  • Status: Resolved
  • Resolution: Fixed
  • OS: windows_2000,windows_xp
  • CPU: x86
  • Submitted: 2003-09-12
  • Updated: 2003-11-26
  • Resolved: 2003-11-26
The Version table provides details related to the release that this issue/RFE will be addressed.

Unresolved : Release in which this issue/RFE will be addressed.
Resolved: Release in which this issue/RFE has been resolved.
Fixed : Release in which this issue/RFE has been fixed. The release containing this fix may be available for download as an Early Access Release or a General Availability Release.

To download the current JDK release, click here.
Other
5.0 b30Fixed
Related Reports
Duplicate :  
Relates :  
Relates :  
Description
When JavaBean is embedded in an ActiveX application(VC++ dialog) using ActiveX bridge, and if the application is de-activated and  then activated again. If the previous focus owner is a Swing component, it doesn't get the focus back.

This is because, the ActiveX application remembers the window which had the focus before the it is de-activated. When the it is activated again, it gives back the focus to the window it rememberd. 

Talked to Denis in AWT team and he suggested that we need to change the AWT code to handle the focus correctly.

Comments
CONVERTED DATA BugTraq+ Release Management Values COMMIT TO FIX: tiger-beta FIXED IN: tiger-beta INTEGRATED IN: tiger-b30 tiger-beta
03-09-2004

SUGGESTED FIX Name: atR10251 Date: 12/03/2003 See attached. ###@###.### 2003-12-03 ======================================================================
03-12-2003

EVALUATION Sounds like a fix is needed for Tiger. ###@###.### 2003-09-15 Name: atR10251 Date: 10/24/2003 The main problem on Windows is that embedded frame has to get notification of activation on native level. Posting only Java events takes no effect. 1. AxBridge: In case when by clicking on application title (or by Tabbing) an embedded frame has to be activated it's control window gets WM_SETFOCUS. First decision taken was to set special message handler on the control window. Thus it would allow us to modify only AWT code. Though this approach had some difficulty when processing messages in the moment of embedded frame destruction or it's new instantiation. In addition it seemed to be working sometimes not stable. So, possibly the better way is to use CAxBridge::OnSetFocus() method that gets called when WM_SETFOCUS comes to the control window. It could send native message to activate embedded frame window directly. 2. IE: In case of an applet no focus messages are sent to the control window. Thus there is no possibility to fix the problem in AWT code only. In this case AxControl::OnFrameWindowActivate() gets called when the control window is to be activated. In both cases we shall correct the code in plugin that in one way or another affects this problem. Now we're testing the latest fix. ###@###.### 2003-10-24 ====================================================================== Name: atR10251 Date: 11/03/2003 By now we have the next problems being worked on: 1. AWT based bean. a) It's default focusable component doesn't get focus by startup. - the problem is that I'm not able to reproduce this, but Plugin team gets this. - verified. b) Strange behaviour was noticed on Win2000. At some moment two buttons look like both being focused. - verified. 2. Swing based bean. Due to it falls into AWT inheritance hierarchy it's default traversal focus policy doesn't work correctly. - this problem is not related to this bug, but affects it; - we're going to file new bug against it; - a workaround was found for this problem. 3. Applet in IE. When one starts an applet it's default component gets focus but it isn't restored when one switches between applications. Though if one clicks that component before switching all is Ok. - Plugin team supposes it has a fix for this problem; - verified. ###@###.### 2003-11-03 ====================================================================== Name: atR10251 Date: 11/03/2003 I could reproduce the problem 1.a pointed above. The reason is the next. EmbeddedFrame gets activated before an applet is added. Thus focus comes onto EmbeddedFrame and makes itself the most recent focus owner. When the applet has been added and EmbeddedFrame gets activated the most recent focus owner is restored. The decision is to perform requestFocusInWindow() for the applet's initial focusable component (when applet has started) in addition to activating EmbeddedFrame on native level. * This will solve the problem but it's better to avoid EmbeddedFrame activation before the applet is inside. ###@###.### 2003-11-03 ====================================================================== Name: atR10251 Date: 11/05/2003 Redundant focus events are generated while plugin is starting. In order to reduce the amount of such events the next decision has been suggested and implemented: - Only those WM_ACTIVATE messages are processed for EmbeddedFrame that: a) were synthesized on our demand but not by Windows itself; b) were received at the time an applet state is APPLET_START. ###@###.### 2003-11-05 ====================================================================== Name: atR10251 Date: 11/10/2003 All the problems pointed above seem to be resolved. A decision to integrate the last AWT & Plugin code changes was taken. ###@###.### 2003-11-10 ====================================================================== Name: atR10251 Date: 11/13/2003 Thus the whole fix touches AWT & Plugin sides. The AWT part of the fix: 1. Adds new public method synthesizeWindowActivation(boolean) to EmbeddedFrame.java. It synthesizes native message to activate EmbeddedFrame window. The method takes affect for Windows & Motif. 2. Monitors KillFocus Windows messages for components inside EmbeddedFrame. In case when focus is going to leave EmbeddedFrame WM_ACTIVATE(WA_INACTIVE) message is to be sent to EmbeddedFrame window. 3. Windows native method AwtComponent::GetTopLevelParentForWindow() didn't work for components inside EmbeddedFrame. It returned a window being top-level for EmbeddedFrame. Possibly such wrong behaviour resulted in some other bugs. So, corrected. The Plugin part of the fix uses synthesizeWindowActivation() method at all the cases EmbeddedFrame is to be activated. ###@###.### 2003-11-13 ======================================================================
13-11-2003