This Bugzilla instance is a read-only archive of historic NetBeans bug reports. To report a bug in NetBeans please follow the project's instructions for reporting issues.
Executive Summary: The IDE must not take control of the help window and instead allow the users to control the help window. Requirements: The User must be able to: a. Position and size the help window as desired, set the font size as desired, and expect the window to stay in that font size, position, height, and width until the user decides otherwise. b. Front the help window, front other windows over the help window, and minimize the help window at any time the user wishes. c. Decide when to open the help window (by pressing F1, clicking a help button, or a Help menu item), decide when to close the help window, and decide when to minimize the help window. Reason: Currently the above is not true. a. The IDE frequently fronts the help window, minimizes the help window, closes the help window, and hides the help window behind other windows at times of its own choosing (and not consistently). In 3.5, the user cannot change the font size. b. The IDE frequently moves and resizes the help window at times of its own choosing. Commonly, when the IDE moves and resizes the help window, it does it in a way that obscures the work that the user needs to see. Many times, the IDE removes the minimize button so the user cannot quickly get the Help window out of the way. c. In an effort to front the help and a dialog window at the same time, the IDE often makes the Help window too thin or too short to use, and, in addition, pushes the border of the dialog (such as a wizard) off the screen such that the user has to move the wizard to expose the Next button or other widget. VOC Support: Issues: 20260, 35961, 34704, 31518, 25470, 32667, 25470 MDE documents (provided upon request) Filed as bugs in bugtraq. Numbers to be provided. Note: This issue is just one of many user issues with the Help windowing system.
Created attachment 13761 [details] Next button obscured by IDE positioning of Help (also no minimize button)
Additional Issuezilla Issues: 22445 34680 37179 38400 36042 20260. Bug filed on behalf of MDE analysis: 4953001 Also, note in the attachment that the IDE will not let you front the wizard in front of the help. If you move the wizard up so that the Next button appears, then the Help window overlaps the wizard and you cannot push the help window behind the wizard. So you must resize Help window smaller or close it (as you cannot minimize it).
Chris, this seems an awful lot like a duplicate of issue 29448 (fix help window z-order/ placement issues). The bottom line on this is we need a proper fix to AWT's window modality problems to make headway - or run help in a separate JVM (which will create interprocess communication bugs and performance issues probably equal in severity to the current problems - they'll just be new and different problems instead of the old familiar ones). The keys to a solution to the entire help window quagmire are JDK bugs 4813288 and 4080029.
When using the IDE with Help open, the IDE repositions Help and, on it's own, closes Help. If you're following steps in a Help page and, for instance, and click a property button that opens a dialog, the IDE moves the Help window as indicated in the comments for this issue and then, when you close the dialog, the IDE closes the Help window. This leaves the user to have to open Help again and navigate again to where he/she was working. If I may be bold in my suggestion without causing offense, I would suggest that any time a program tries to decide layout and usage issues for the user, it will choose incorrectly for more users than it will choose correctly. Where the user is expected to have the technical ability to make layout and configuration choices, it is better to leave those choices to the user - especially in the case of this Help issue. Doing nothing in this case is easier than doing something.
this issue belongs to core/help system
Just to clarify, doing nothing in this situation is not an option: If a modal dialog is opened, and we do nothing, the help window will be disabled. That's not too useful. The ugly workaround that causes all the trouble is that in order to keep the help window open, it is necessary to reparent the help component to a new child dialog of any open modal dialog, whenever a new modal dialog is opened. This has the side effect of fronting it, etc. Re the repositioning stuff, yes, that's a little crazy; there was some requirement that the help not get in the way of modal dialogs (and since it is a child dialog, it will be further up in the z order than the current modal dialog). So the problem is that doing nothing means the help window is broken whenever a modal dialog is opened; the workaround for that causes the myriad other problems. What we need is to be able to specify to AWT that one frame, the help window, should not be affected by modal dialogs.
fixed for jdk 1.5.0_03/_04 and later. On those jdks the IDE won't attempt to reparent and move the help window arround