Bugzilla – Full Text Bug Listing
| Summary: | [Wizards] Wrong help context for the New Wizards when focus is on the Next/Prev buttons (based on the NewWizardAction) | ||
|---|---|---|---|
| Product: | [Eclipse Project] Platform | Reporter: | ALOK MANJREKAR <alokmanjrekar> |
| Component: | UI | Assignee: | Platform UI Triaged <platform-ui-triaged> |
| Status: | CLOSED WONTFIX | QA Contact: | |
| Severity: | major | ||
| Priority: | P3 | CC: | daniel_megert |
| Version: | 4.2 | ||
| Target Milestone: | --- | ||
| Hardware: | PC | ||
| OS: | Windows 7 | ||
| Whiteboard: | stalebug | ||
|
Description
ALOK MANJREKAR
They can get help from Help>Help Contents, so there is a workaround and no data loss. PW Hello Paul,
Yes - Help from Help-> Help Contents would work. But that would need the user to search for it.
Launching the appropriate help from the new-wizard would save a lot of time.
Our documentation team was kind of keen that we somehow address this issue. Since we would be releasing our product next month with eclipse 4.2, which would not have this fix, what do you think is the best way to address this issue?
I was wondering if we add the following piece of code within our wizardPage implementations for the time being until this issue is addressed within the eclipse platform
public void setVisible(boolean visible) {
super.setVisible(visible);
// This is to address INFA368369 - which is an eclipse issue
if(visible) {
PlatformUI.getWorkbench().getHelpSystem().setHelp(getShell(), HELP_CONTEXT_ID);
}
}
What do you think of this workaround? If not, do you suggest any other approach?
Also - do you know which eclipse release can we expect this to be addressed?
Same problem in 3.x and 'NewWizardShortcutAction' has the same issue. (In reply to ALOK MANJREKAR from comment #2) > I was wondering if we add the following piece of code within our wizardPage > implementations for the time being until this issue is addressed within the > eclipse platform > > > public void setVisible(boolean visible) { > super.setVisible(visible); > // This is to address INFA368369 - which is an eclipse issue > if(visible) { > PlatformUI.getWorkbench().getHelpSystem().setHelp(getShell(), > HELP_CONTEXT_ID); > } > } > > What do you think of this workaround? This will be too early i.e. it will be overwritten by the action. > If not, do you suggest any other approach? Note the nicest code, but it should do the trick: add the following code to WizardPage.setControl(Control): final Shell shell= getShell(); shell.getDisplay().asyncExec(new Runnable() { public void run() { if (!shell.isDisposed()) PlatformUI.getWorkbench().getHelpSystem().setHelp(shell, helpId); } }); Hi Dani, Thanks for looking at this. I tried the approach to override setVisible() of the wizardPage in a couple of places, and it seems to be working fine. You have mentioned that "This will be too early i.e. it will be overwritten by the action." It is actually not too early. SetVisible() of the WizardPage is called only when the wizardpage is about to show. The NewWizardAction sets the hardcode helpID on the shell of the WizardDialog before calling open() on it. So, it would definitely be called before the setVisible() of the WizardPage. I believe doing the workaround in the setVisible() of the WizardPage will not be too early, and should work. Could you please have a look again and confirm my understanding? (In reply to ALOK MANJREKAR from comment #4) > Hi Dani, > > Thanks for looking at this. > I tried the approach to override setVisible() of the wizardPage in a couple > of places, and it seems to be working fine. > > You have mentioned that > "This will be too early i.e. it will be overwritten by the action." > > It is actually not too early. SetVisible() of the WizardPage is called only > when the wizardpage is about to show. > The NewWizardAction sets the hardcode helpID on the shell of the > WizardDialog before calling open() on it. So, it would definitely be called > before the setVisible() of the WizardPage. > I believe doing the workaround in the setVisible() of the WizardPage will > not be too early, and should work. > > Could you please have a look again and confirm my understanding? Your understanding is wrong, at least when it comes to the first wizard page. The first page is created (and made visible) when the wizard dialog is created. This happens before the helpId is set in the action. I see what you mean.
But the suggestion that you gave
**************************************
Note the nicest code, but it should do the trick: add the following code to WizardPage.setControl(Control):
final Shell shell= getShell();
shell.getDisplay().asyncExec(new Runnable() {
public void run() {
if (!shell.isDisposed())
PlatformUI.getWorkbench().getHelpSystem().setHelp(shell, helpId);
}
});
***************************************
I assume you meant over-riding the setControl() in the wizardPage implementation to add the above logic.
The setControl() of the wizardPage gets called even before setVisible().
So if setVisible() is too early, then setControl() would be even earlier and will not work.
Any other suggestions?
Btw .. Just to add to my previous comment .. Would this original bug which appears when NewWizardAction is used be fixed in the next eclipse release? I noticed that we use NewWizardAction, only when there are multiple items involved in a category. So the first page that gets shown is a generic page that lists the items in the category. The actual wizard pages are created only when the "Next" is activated on the initial generic wizard page. So the workaround that we have to add the extra logic inside "setVisible" should still work fine. Since setControl() of wizardPage gets called even before setVisible(), adding the logic in setControl() doesnt seem like a better solution at the moment. What do you think? (In reply to ALOK MANJREKAR from comment #7) > Btw .. Just to add to my previous comment .. Would this original bug which > appears when NewWizardAction is used be fixed in the next eclipse release? No one is working on that. 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. As such, we're closing this bug. If you have further information on the current state of the bug, please add it and reopen this bug. 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. -- The automated Eclipse Genie. |