JDK-4866704 : JavaHelp Windows interaction with modal dialogs
  • Type: Enhancement
  • Component: client-libs
  • Sub-Component: java.awt
  • Affected Version: 1.4.1
  • Priority: P4
  • Status: Resolved
  • Resolution: Fixed
  • OS: windows_2000
  • CPU: x86
  • Submitted: 2003-05-20
  • Updated: 2005-05-21
  • Resolved: 2005-05-21
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 b38Fixed
Related Reports
Relates :  
JDK-4813288 - Need a way to exempt some windows from disablement when a modal dialog is shown
Description
Name: pa48320			Date: 05/20/2003

When I am on a dialog and I bring up the help window I can still perform functions on the dialog, which is expected. The help window is dependent on the dialog itself (i.e. modal) and shouldn't be.  I'm unable to display the dialog in the foreground when the help window is open, which will definitely irritate users who want to enter information and go back and forth between the dialog and help window.

Also, if the help window is open and I select a button on the dialog that opens another dialog, I can't close the help window (until I close the new dialog).

And, if I select the help button on the new dialog, it replaces the current help window.

In my experience with software standards, help windows should be in no way dependent on the dialog from which they are selected (i.e. non-modal).  I should be able to select a help window and keep it open forever, and I should be able to display multiple help windows at the same time.  I should also have the ability to switch between the dialog itself and the help windows associated, rather than having to move the help window to a different part of the screen so I can enter information in the dialog.

======================================================================
Comments
EVALUATION This resport should be divided into multiple reports. Mainly the issues here are around the capability of having additional modality support for dialogs and windows. Currently the AWT doesn't allow any modality other than the modal or non-modal. This causes the non-modal dialogs like help to be blocked unless they are reparented to the modal dialog. > When I am on a dialog and I bring up the help window I can still perform > functions on the dialog, which is expected. The help window is dependent on > the dialog itself (i.e. modal) and shouldn't be. The Help window is required to be dependent on the dialog otherwise no events will be received in the help window. Unfortunately there is not a modal state that allows windows to received events regardless of modality. > I'm unable to display the dialog in the foreground when the help window is > open, which will definitely irritate users who want to enter information and > go back and forth between the dialog and help window. Works on Solaris but not Windows XP. > Also, if the help window is open and I select a button on the dialog that > opens another dialog, I can't close the help window (until I close the new > dialog). If the new dialog is also modal and you want this work as you described you would need to reset the activationWindow for the help window to be the new dialog window so the help window would receive events. Otherwise if the new dialog is a not modal but just a child of the modal dialog and it doesn't work it would be an awt bug. > And, if I select the help button on the new dialog, it replaces the current > help window. Naturally it will as it must because the help window can't get any events from a modal dialog unless it's a parent. It's an unfortunate consequence of modal dialogs > In my experience with software standards, help windows should be in no way > dependent on the dialog from which they are selected (i.e. non-modal). I > should be able to select a help window and keep it open forever, and I should > be able to display multiple help windows at the same time. Modality of the help window is dependent on the underlying infrastructure in the AWT which does not exist. Current modality options are on or off. There is no capability for help modality in the java platform. If your suggesting an API that would accomodate this please one another RFE for such a feature. As far as displaying multiple help windows you can do that now. > I should also have > the ability to switch between the dialog itself and the help windows > associated, rather than having to move the help window to a different part of > the screen so I can enter information in the dialog. This is possibly a bug on windows. ###@###.### 2003-05-20 Name: osR10079 Date: 07/23/2003 This ref should be implemented along with all other modality schemes. But it's too late for tiger, let's wait next release. ###@###.### 2003-07-23 ====================================================================== This is the same issue as 4813288: we need an API to exclude some top-level windows from modality. Both of these features are implemented as a part of 4080029. ###@###.### 2005-05-04 12:10:54 GMT
04-05-2005