The reason why I need the state is a self written source provider. This provider provides information on state changes of views (no matter whether active or not). This approach eliminates source providers for each view but requires some kind of conditional evaluation. Therefore the test for the perspective id and requirement to get the current activation state.

My solution is really ugly. To get the current activation state I am using a PropertyTester that queries the current command's handler state. Is there any other way to not drop the single source provider?

What do you mean exactly with writing out the handler's state at the end of execute(*)?

Providing additional information via the the source provider certainly is an option. But i would prefer not mixing up information that actually do not belong together, because that might make future reuse difficult.

On 01/09/2011 01:24 PM, ben wrote:
> Thanks for your reply. It is the activeWhen i need.
>
> What do you mean exactly with writing out the handler's state at the end
> of execute(*)?

That was me trying to understand what exactly needs "the state" and what
provides "the state".

A source provider provides one or more variables to the
IEvaluationService. It notifies the IEvaluationService that the
variable value has changed, and then the IEvaluationService takes care
of re-evaluating everybody that consumes that variable. Anything in the
system can provide state to a source provider (We update variables on
SWT events, in response to property listeners, and occasionally when
code programmatically sets information on a "Manager" provided by a
plugin activator).

The activeWhen expression determines if a given handler is active (by
consuming one or more variables from the IEvaluationService, + running
any property testers that are listed).

Your view can produce state, and presumably owns its runtime model (or
deals with the manager that does).

Handlers don't have state, they act on the state of the system. The
questions I was asking were to try and find out where your state is
coming from. Your view?

To clarify, the views are extensions of ViewPart. Each view consists of two parts, a query part and a result display part. Query parts are used to select the data to display. The source provider provides a variable that changes if the query of any view changes and contains the view part and the query object. This information is used to determine the activation of handlers. Logically, this approach forces reevaluation of expressions every time a view's query has changed, no matter whether the handler is related to the changed view or not.

> I'm not sure what you mean, exactly. The whole thing is an if statement:
>
> if (evaluateActiveWhen(activeWhen)) { makeHandlerActive(handler); }

That was a missunderstanding. What i meen is an if-expression that can be used within the activeWhen statement. Something like: