Some Eclipse Foundation services are deprecated, or will be soon. Please ensure you've read this important communication.
Bug 360357 - CanExecute of Handler are checked ever 500ms
Summary: CanExecute of Handler are checked ever 500ms
Status: CLOSED DUPLICATE of bug 385394
Alias: None
Product: Platform
Classification: Eclipse Project
Component: UI (show other bugs)
Version: 4.2   Edit
Hardware: All All
: P3 normal (vote)
Target Milestone: 4.4 M5   Edit
Assignee: Platform UI Triaged CLA
QA Contact: Paul Webster CLA
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2011-10-09 10:06 EDT by Hannes Niederhausen CLA
Modified: 2014-01-15 06:43 EST (History)
6 users (show)

See Also:

Attachments
Add an attachment (proposed patch, testcase, etc.)

Note You need to log in before you can comment on or make changes to this bug.
Description Hannes Niederhausen CLA 2011-10-09 10:06:43 EDT 
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
Comment 1 Paul Webster CLA 2011-10-09 11:46:07 EDT 
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
Comment 2 Simon Chemouil CLA 2011-10-10 05:32:46 EDT 
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.
Comment 3 Paul Webster CLA 2011-10-10 07:36:37 EDT 
See also bug 358658

PW
Comment 4 Oleg Besedin CLA 2011-10-11 10:32:05 EDT 
See also bug 358158 , bug 359082 , bug 358494 .
Comment 5 Paul Webster CLA 2014-01-14 13:29:25 EST 

*** This bug has been marked as a duplicate of bug 385394 ***