Bugzilla – Full Text Bug Listing
| Summary: | [Commands] instrumentation: Listening to commands invoked from menu or key | ||
|---|---|---|---|
| Product: | [Eclipse Project] Platform | Reporter: | Channing Walton <channingwalton> |
| Component: | UI | Assignee: | Douglas Pollock <douglas.pollock> |
| Status: | VERIFIED FIXED | QA Contact: | |
| Severity: | enhancement | ||
| Priority: | P2 | CC: | dejan, eclipse, eclipse, n.a.edgar, sxenos |
| Version: | 2.1 | ||
| Target Milestone: | 3.1 M6 | ||
| Hardware: | All | ||
| OS: | All | ||
| Whiteboard: | |||
|
Description
Channing Walton
Note that in 3.0, all SWT events get routed through the event filters added using Display.addFilter. I also suggest checking out the Eclipse Instrumentation Framework at: http://dev.eclipse.org/viewcvs/index.cgi/%7Echeckout%7E/platform-ui- home/instrumentation/index.html *** Bug 87224 has been marked as a duplicate of this bug. *** Okay, I'm writing up the implementation now, and I have one question. Is it useful to receive notification of an attempt to execute a command, even if it doesn't have a valid handler? The mechanism will work something like this: Command.addExecutionListener(IExecutionListener) Command.removeExecutionListener(IExecutionListener) CommandManager.addExecutionListener(IExecutionListener) CommandManager.removeExecutionListener(IExecutionListener) IExecutionListener.aboutToExecute(String commandId,ExecutionEvent) IExecutionListener.executionFailed(String commandId,ExecutionException) IExecutionListener.executionSucceeded(String commandId,Object returnValue) Or, perhaps a 4th method on IExecutionListener? IExecutionListener.notHandled(String commandId,NotHandledException) Input is appreciated. Another question. Right now, commands will return an arbitrary object. Would it be better if I forced commands to return a particular type of object? (Note: this return value would be available in the "executionSucceeded" method.) Suggest just passing a single event object in the listener methods, and encapsulating the command id, (optional) result and (optional) exception in the event object. Rather than having separate events for success or failure, I suggest having just one, where the event indicates whether it succeeded or failed. For naming conventions, the advisors use "pre"/"post" prefixes, e.g. WindowAdvisor.preWindowOpen/postWindowOpen. The regular workbench interfaces use the "ed" suffix, e.g. IWorkbenchWindowListener.windowOpened. If they supported pre-notification, the suffix "ing" would be used, e.g. IWorkbenchWindowListener.windowOpening. I'd be fine with either convention for the command listeners. > Is it useful to receive notification of an attempt to execute a command, > even if it doesn't have a valid handler? Not sure. Let's leave it out if there's no proven need. > Would it be better if I forced commands to return a particular type of object? I don't see any need to constrain the return type. Fixed in CVS. You can get at this in a couple of ways.
ICommandService commandService = (ICommandService)
Workbench.getService(ICommandService.class);
commandService.addExecutionListener(...);
...
Command command = commandService.getCommand("id");
command.addExecutionListener(...);
As a note, I am note actually modifying the instrumentation plug-in. I'm not sure if this is clear. If someone wants the instrumentation plug-in to take advantage of this API, please open a separate bug. Verified that the API exists on ICommandService. Any bugs with the actual service (if any) can be dealt with after 3.1 M6. Excellent, thanks. |