Community
Participate
Working Groups
I20070206-0010 File/New/Other/User Assistance/Cheat sheet In the editor select item Click on the Browse button in the command section Select Views/Ant Click on the execute button Expected result, the Ant view opens. Actual result, Messagebox No activeWorkbenchWindow found This is a recent regression caused because some of the UI commands which used to ignore the application context now expect it to be non-null. The fix is straightforward and I've already made a similar change in org.eclipse.ui.cheatsheets. I will attach a patch.
This is not as easy to fix as I had expected. Below is the patch which I had expected would fix the problem. While this improves the situation by creating an application context it is not an application context that enables the open view command to work. ### Eclipse Workspace Patch 1.0 #P org.eclipse.pde.ui Index: src/org/eclipse/pde/internal/ui/commands/CommandDetails.java =================================================================== RCS file: /cvsroot/eclipse/org.eclipse.pde.ui/src/org/eclipse/pde/internal/ui/commands/CommandDetails.java,v retrieving revision 1.11 diff -u -r1.11 CommandDetails.java --- src/org/eclipse/pde/internal/ui/commands/CommandDetails.java 4 Feb 2007 03:11:57 -0000 1.11 +++ src/org/eclipse/pde/internal/ui/commands/CommandDetails.java 6 Feb 2007 23:40:58 -0000 @@ -26,6 +26,7 @@ import org.eclipse.core.commands.ParameterizedCommand; import org.eclipse.core.commands.common.CommandException; import org.eclipse.core.commands.common.NotDefinedException; +import org.eclipse.core.expressions.IEvaluationContext; import org.eclipse.jface.dialogs.IMessageProvider; import org.eclipse.jface.dialogs.MessageDialog; import org.eclipse.osgi.util.NLS; @@ -50,12 +51,15 @@ import org.eclipse.swt.widgets.Composite; import org.eclipse.swt.widgets.Label; import org.eclipse.swt.widgets.Text; +import org.eclipse.ui.IWorkbench; +import org.eclipse.ui.PlatformUI; import org.eclipse.ui.forms.events.HyperlinkAdapter; import org.eclipse.ui.forms.events.HyperlinkEvent; import org.eclipse.ui.forms.widgets.ExpandableComposite; import org.eclipse.ui.forms.widgets.FormToolkit; import org.eclipse.ui.forms.widgets.ImageHyperlink; import org.eclipse.ui.forms.widgets.Section; +import org.eclipse.ui.handlers.IHandlerService; public class CommandDetails { @@ -196,11 +200,23 @@ return pCommand; } + private IEvaluationContext getCurrentState() { + IWorkbench wb = PlatformUI.getWorkbench(); + if (wb != null) { + Object serviceObject = wb.getAdapter(IHandlerService.class); + if (serviceObject != null) { + IHandlerService service = (IHandlerService)serviceObject; + return service.getCurrentState(); + } + } + return null; + } + private class ExecCommand extends HyperlinkAdapter { public void linkActivated(HyperlinkEvent e) { ParameterizedCommand pCommand = buildParameterizedCommand(); - try { - Object obj = pCommand.executeWithChecks(null, null); + try { + Object obj = pCommand.executeWithChecks(null, getCurrentState()); String resultString = null; if (obj instanceof String) { resultString = (String)obj;
Paul, What has happened in this space recently that would cause this breakage? Also, it would be good if you could advise on how we can make the Command Composer all that it can be.
We've started converting the UI handlers so they now "don't go global" for things like the active workbench, they get it from the application context. So in the Show View example, it calls IWorkbenchWindow window = HandlerUtil.getActiveWorkbenchWindowChecked(event); which is what is now causing the exception. There are unchecked version in HandlerUtil as well (it's API). Your code looks fine, here's our 3.2 compatible example of an IActionDelegate that the executes a ParameterizedCommand: http://dev.eclipse.org/viewcvs/index.cgi/org.eclipse.ui.tests/Eclipse%20UI%20Tests/org/eclipse/ui/tests/api/GenericCommandActionDelegate.java?view=co The only thing I think that's different in your example is my IActionDelegate calls "handlerService.executeCommand(parameterizedCommand, null);" instead of extracting the application context out of the handler service. I would go this way unless you need to go another. In your own handlers, I would also start taking advantage of HandlerUtil ... it really makes the code smaller :-) You execute your command from your Command Composer dialog, correct? It could be that my updating the show view handler has restricted it to being executed from the workbench window. If you need to be able to execute the show view command from a dialog, I've opened bug 173213 to track it. PW
Brian, let's see how much we can salvage for M5 without blowing up. Top Committer nominee Paul Webster is very helpful and owns the commands framework, so if you need clarifications, please feel free to bug him ;)
Hey Mike, when it comes to cheatsheet editor week, can you take a look at this bug. If not, send it back to me.
While I wasn't able to fix this in 3.3 (see bug 173213) I might have a patch or 2 that will help you in the short term. Maybe early next week. PW
Created attachment 64258 [details] Command Details v01 Matching PDE patch that works with bug 173213 Basically: 1) get a snapshot of the application context while in the CheatSheet editor 2) ask the HandlerService to execute the parameterized command with a specific context (the handler service will select the correct handler and call execute). This is a draft patch, but show view works correct from the dialog. PW
What does PDE think of this approach? PW
Hi Paul, Your approach sounds good and your changes look very reasonable. I was not able to test your patch because HandlerService#executeCommandInContext does not exist in HEAD for org.eclipse.ui.workbench (expected as you have not finalized yet) Thanks thus far.
Hi Mike, Perhaps you should apply the patch in bug 173213 to org.eclipse.ui.workbench to verify that both patches work well together.
(In reply to comment #9) > Hi Paul, > > Your approach sounds good and your changes look very reasonable. OK, if this is an acceptable approach I'll apply my patch this weekend and take another pass through the PDE patch to see that it's clean and consistant. Then if you can review it on Monday, that would be great. If you want to pre-test, I'd use the Thursday 00:10 or later nightly build and check out org.eclipse.ui.workbench from HEAD (it's not compatible with the I build any more because of changes made with SWT). PW
Created attachment 64549 [details] Command Details v02 Before the Dialog is created, take a snapshot of the application context. Then the CommandComposerPart will use the context snapshot if available. PW
Comment on attachment 64549 [details] Command Details v02 See main bug report for comments
Reviewed and tested patch. Looks good. Patch released to HEAD. * Added TODOs to move off of internal class after API freeze: org.eclipse.ui.internal.handlers.HandlerService; * When defaulting to the global application context, capture the execution return value: obj = service.executeCommand(pCommand, null); Paul, Thanks a lot for the fix and all your hard work. Sorry for not being able to review this in time for the I-Build.
