Community
Participate
Working Groups
IContextProvider currently cannot be used for wizards/dialogs. The workaround is to add a custom help listener, create an IContext and call the help UI directly with it. However it would be much cleaner if an IContextProvider could be used.
(In reply to comment #0) My vote for this. Eclipse should have a consistent implementation for dynamic context-sensitive help, including dialogs. Why force extenders/adopters to "roll their own" to implement a consistent context-sensitive help interface? Any hope of this one getting into 3.3 release? Thanks.
Can you clarify? Wizards extend TrayDialog that shows help on F1 or when ? button is pressed. If your dialog extends TrayDialog, you will get this behaviour yourself. What else is needed?
(In reply to comment #2) We want dynamic context-sensitive help for wizards and dialogs. The standard dialog/wizard helpListener seems to be unaware of IContextProvider. So if we declare a dialog class that both extends TrayDialog and implements IContextProvider, we have to implement our own helpListener (instead of dialog-based WorkbenchHelpSystem$WorkbenchHelpListener.helpRequested) to capture the help events and support IContextProvider methods.
I was about to add Curtis to the cc list to get clarification when I realized that Curtis opened the defect in the first place :-).
Dave is right.. help is currently not looking for IContextProviders with dialogs. It only checks for workbench parts (views, editors). It is possible to roll your own solution using the API, but it would be better if clients can just use IContextProviders and help would be aware of them for dialogs.
*** Bug 187645 has been marked as a duplicate of this bug. ***
I think that the way to do this would be to modify DefaultHelpUI.displayContextAsHelpTray to have a test something like this: if (tray instanceof HelpTray) { ReusableHelpPart helpPart = ((HelpTray)tray).getHelpPart(); if (dialog instanceof IAdaptable) { IContextProvider provider = (IContextProvider) ((IAdaptable) dialog).getAdapter(IContextProvider.class); if (provider != null) { helpPart.showPage(IHelpUIConstants.HV_CONTEXT_HELP_PAGE); helpPart.update(provider, context, null, controlInFocus); return; } In addition the code in ContextHelpPart which determines the context based on the control which has focus would need to be modified to behave differently when there was an IContextProvider. See also Bug 206956 which should be fixed before looking into this bug. This will probably not make it into Eclipse 3.4.
This bug hasn't had any activity in quite some time. Maybe the problem got resolved, was a duplicate of something else, or became less pressing for some reason - or maybe it's still relevant but just hasn't been looked at yet. If you have further information on the current state of the bug, please add it. The information can be, for example, that the problem still occurs, that you still want the feature, that more information is needed, or that the bug is (for whatever reason) no longer relevant.