Bug 173288 - [Help][Context] Support wizards/dialogs for IContextProvider
Summary: [Help][Context] Support wizards/dialogs for IContextProvider
Status: NEW
Alias: None
Product: Platform
Classification: Eclipse Project
Component: User Assistance (show other bugs)
Version: 3.3   Edit
Hardware: PC Windows XP
: P3 normal with 2 votes (vote)
Target Milestone: ---   Edit
Assignee: platform-ua-inbox CLA
QA Contact:
URL:
Whiteboard:
Keywords:
: 187645 (view as bug list)
Depends on:
Blocks: 275433
  Show dependency tree
 
Reported: 2007-02-07 11:09 EST by Curtis d'Entremont CLA
Modified: 2019-09-06 15:29 EDT (History)
2 users (show)

See Also:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Curtis d'Entremont CLA 2007-02-07 11:09:31 EST
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.
Comment 1 Dave Resch CLA 2007-04-20 16:21:12 EDT
(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.
Comment 2 Dejan Glozic CLA 2007-04-20 16:24:28 EDT
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?
Comment 3 Dave Resch CLA 2007-04-20 17:23:39 EDT
(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.
Comment 4 Dejan Glozic CLA 2007-04-20 17:55:57 EDT
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 :-).
Comment 5 Curtis d'Entremont CLA 2007-04-23 10:31:42 EDT
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.
Comment 6 Chris Goldthorpe CLA 2007-10-22 12:56:37 EDT
*** Bug 187645 has been marked as a duplicate of this bug. ***
Comment 7 Chris Goldthorpe CLA 2007-10-22 13:05:13 EDT
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.
			
Comment 8 Eclipse Webmaster CLA 2019-09-06 15:29:53 EDT
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.