Bugzilla – Full Text Bug Listing
| Summary: | CanExecute of Handler are checked ever 500ms | ||
|---|---|---|---|
| Product: | [Eclipse Project] Platform | Reporter: | Hannes Niederhausen <hniederhausen> |
| Component: | UI | Assignee: | Platform UI Triaged <platform-ui-triaged> |
| Status: | CLOSED DUPLICATE | QA Contact: | Paul Webster <pwebster> |
| Severity: | normal | ||
| Priority: | P3 | CC: | daniel.rolka, daniel_megert, eclipse, ob1.eclipse, pelder.eclipse, remy.suen |
| Version: | 4.2 | ||
| Target Milestone: | 4.4 M5 | ||
| Hardware: | All | ||
| OS: | All | ||
| Whiteboard: | |||
The listener was the old way, and had a lot of problems (i.e. the handler and the command shouldn't have state, except in the context they could be executed in). The toolitems must ask the @CanExecute question in their context (window, part, or dialog). We used to allow them to be re-asked in their context when a consumed variable (from the IEclipseContext) changed, but that was not performant. As it turns out asking every 500ms or so is more performant. But we are still looking at this arrangement to see if we can improve it. PW As far as I know this is only true for MHandledToolItems. For the record, when profiling our application, this came first in CPU usage. Costs a lot especially if the @CanExecute method is intensive. In our application, we have similar buttons/toolitems that are bound to a command whose state is refreshed only when the @CanExecute parameters change (using RAT). The class that does this does not imply any change of interface (afaik), and we might be able to share it (authorization pending) so we can use it as an inspiration for a patch, if interested. See also bug 358658 PW See also bug 358158 , bug 359082 , bug 358494 . *** This bug has been marked as a duplicate of bug 385394 *** |
Hi, I created a CommandHandler using the @CanExecute and @Execute annotations. Inside the annotated can execute method I added a tiny log message to check how the toolbar items in my e4 rcp are updated. I was suprised that their seems to be a thread which checks the state constantly, which is in my opinion a great waste of CPU time. I'm not sure if I did something wrong but if not I stonrgly suggest to extend the API for execution to annotate methods to add or remove a listnener. I suggest some sort of minimalistic listener interface like: interface IStateListener { public void stateChanged(); } I know this would require the Handler implementations to be more complex, but would decrease the CPU usage. The annotations could look like: @AddStateListener @RemoveStateListener