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.

Bug 22681 - When window has multiple help map IDs, only core help id works
Summary: When window has multiple help map IDs, only core help id works
Status: CLOSED FIXED
Alias: None
Product: debugger
Classification: Unclassified
Component: Code (show other bugs)
Version: -FFJ-
Hardware: Sun Solaris
: P2 blocker (vote)
Assignee: Marian Petras
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2002-04-23 03:00 UTC by Ann Rice
Modified: 2003-06-30 17:28 UTC (History)
2 users (show)

See Also:
Issue Type: DEFECT
Exception Reporter:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Ann Rice 2002-04-23 03:00:13 UTC
When a core IDE window or dialog box is used by a
module (such as Solaris Native Languages Support)
and the contents of the window or dialog are
different than those for the core IDE, a different
help topic needs to be displayed by the Help
button and/or F1 key. But even though the module
assigns a different help map ID to the window or
dialog, the help map ID assigned by the core IDE
always takes precedence, and the help topic
associated with that help map ID is always
displayed. For example, even though the SNLS code
assigns its own help map ID to the Add Breakpoints
dialog box (which has completely different
contents when the dbx Debugger is active),
clicking the Help button displays the online help
topic for the core IDE contents of the Add
Breakpoints window. So the user is seeing online
help that is incorrect for the implementation of
the dialog that he is currently using.
Comment 1 Jan Jancura 2002-04-25 10:03:07 UTC
=> core team
Comment 2 Jesse Glick 2002-04-25 14:24:47 UTC
Can't rule out a core bug yet, but I see no evidence of it. So far all
I see is that some dialog in the debugger module has the wrong help
ID. I know nothing about the interaction between the different
debugger modules, so please do not reassign to core without complete
details of what dialog this is (class name please!), where in code the
base debugger module assigns the help ID, where the extension module
tries to override it. Nicer would be a standalone test case not using
the debugger module at all, so the problem can be demonstrated without
going through a lot of unrelated code.

Remember that the core NbPresenter first looks for a direct
DialogDescriptor.helpCtx, and if there is none it will also check the
contained component for a helpID JComponent client property. Setting
the help context directly on the descriptor is better. Maybe the
debuggercore use the descriptor's helpCtx property, and the extension
module does something else that has no effect?
Comment 3 Jan Jancura 2002-05-02 17:46:12 UTC
After consultation with John-Jullion Ceccarelli and Patrick Keegan
(documentation writers), I changed code of the Add Breakpoint dialog
in the
following way:

- HelpCtx is taken from a customizer of a selected breakpoint type.
- If the customizer does not provide any HelpCtx, a default help is used
  (In NB 3.4, the page describing Java breakpoint types is the default.
  The restriction was that new help pages cannot be added - it is too
  late.)


Comment 4 Jan Jancura 2002-05-02 17:46:59 UTC
fixed in main trunk
Comment 5 Marian Petras 2002-05-07 13:44:41 UTC
Fixed also in branches 'release33' and 'orion_fcs'.
Comment 6 Marian Petras 2002-05-14 19:13:16 UTC
This bug is fixed in NetBeans but not in Orion. Why? Here is the story:

When I fixed the bug in NetBeans (the fix allowed other modules to
specify their own Help IDs), I called to Ann Rice to ask her, which
developer working on SNLS should I contact in order to make the bug
fixed also in Orion. She told be that Tor Norbye is the right person -
so I e-mailed to Tor Norbye. But Tor Norbye was on vacation that time.
When Tor returned from vacation, he told me that George Hernandez was
working on help topic issues. So I sent an e-mail to George Hernandez.
George Hernandez was on vacation that time. When he returned, he read
my e-mail and tried to make necessary changes in Orion code - but it
was too late, the change of code (although very simple and without
risk) was refused.
Comment 7 Marek Grummich 2003-01-13 09:41:26 UTC
Verified
Comment 8 Quality Engineering 2003-06-30 17:28:41 UTC
Resolved for 3.3.x or earlier, no new info since then -> closing.