Bug ID: JDK-6365992 REG: Showing and disposing a native print dialog makes the main frame inactive, Win32

Versions (Unresolved/Resolved/Fixed)

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.

JDK 6
6 b71Fixed

I have a frame with few buttons on it. On clicking one of the buttons, I am bringing up the native print dialog. Once the dialog is shown, I am pressing 'ESC' and the dialog is disposed. After that, the frame becomes inactive and focus does not come back to the same component automatically. I would expect the frame to be active and focus should remain with the same component which brought up the dialog.

This is a regression in Mustang introduced in b53. This is reproducible only on Win32 and not on XToolkit. It works fine on Tiger-FCS and Mustang-b51. 

Run the attached application. Press the button. A native print dialog will come up. Press 'ESC'. Check the main frame. If it is not active, the bug is reproduced.

SUGGESTED FIX -bash-2.05b$ sccs diffs -C awt_PrintDialog.cpp ------- awt_PrintDialog.cpp ------- * /tmp/sccs.kbjTWZ 2005-12-30 16:59:49.000000000 +0300 --- awt_PrintDialog.cpp 2005-12-30 16:41:38.000000000 +0300 *********** * 114,119 **** --- 114,120 ---- DASSERT(control != NULL); AwtComponent awtParent = (parent != NULL) ? (AwtComponent )JNI_GET_PDATA(parent) : NULL; + HWND hwndOwner = awtParent ? awtParent->GetHWnd() : NULL; PRINTDLG pd; memset(&pd, 0, sizeof(PRINTDLG)); ************* * 147,155 **** AwtDialog::CheckUninstallModalHook(); ! if (awtParent != NULL) { ! AwtDialog::ModalNextWindowToFront(awtParent->GetHWnd()); ! } } env->DeleteGlobalRef(peerGlobalRef); --- 148,154 ---- AwtDialog::CheckUninstallModalHook(); ! AwtDialog::ModalNextWindowToFront(hwndOwner); } env->DeleteGlobalRef(peerGlobalRef);
30-12-2005
EVALUATION This is a regression and before the fix for 6302514 the parent (active window) was activated after the print dialog hidden. According the suggested fix the enabled/visible window which is chosen by EnumThreadWindows will be activated. I'm unsure that behaviour will be the same as before 6302514. But unfortunately, in order to fix it more compatible we should do the fix for 6302514 more complicated or implement the storing of the previous active window. In case of this suggested fix the code looks more simple and clear.
30-12-2005
EVALUATION According to implementation (awt_PrintDialog.cpp) we don't activate any window (ModalNextWindowToFront) if the parent is null.
23-12-2005
EVALUATION It was caused by the fix where the parent of PrintDialog (not sure for others) became NULL. This is a regression in 6302514. We should decide if our focusing system should work differently and how.
22-12-2005
EVALUATION It seems not to be a regression after 4810575. Should look on 5048370 and 6225560. Reproduced with JDK6.0b64.
21-12-2005

Relates :	JDK-6367771 - Specification for modal dialog hidden should be corrected
Relates :	JDK-6302514 - XToolkit: Toolkit modal dialog getting blocked by Page/Print dialog
Relates :	JDK-6379599 - REG: Showing and disposing a native page dialog makes the main frame inactive, Win32