[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [platform-ui-dev] command enablement in view toolbar
- From: Paul Webster <pwebster@xxxxxxxxxxxxxxxxxxx>
- Date: Thu, 4 Feb 2010 09:22:22 -0500
- Delivered-to: firstname.lastname@example.org
- Domainkey-signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:content-type :content-transfer-encoding; b=IUivrpxyCoePF0QLKwnGqFbBU9SbC0EeoCvnBPq/DQ+BhQ8HdChUsXKB66bjIbMWNM Sel/crSJ079Wg4wyxGXsLOxz+KW2kt/qVf3cX4DKLJu5xRLAmvKkg3xsR1J2oNw0tsn3 lqrtqfbkYDX2ifvePjeoQNgmvSD92kNNXc+NQ=
On Wed, Feb 3, 2010 at 5:17 PM, Pawel Piech <pawel.piech@xxxxxxxxxxxxx> wrote:
> I'm trying to use a commands in a view toolbar and I have a problem with
> enablement.Â My command's enablement should depend on the view in which it
> appears, but the command handler is global so it changes whenever the active
> part changes.Â This makes the command look broken when my view is not the
> active part.
I think there's 2 parts to this problem, the fact that the command has
one active handler and the global state.
If you activate your handler in your view, then when your view is not
active the tool item will be disabled. If you have multiple views
that contribute that handler, then the visible tool items in all of
the views will reflect the state of the active view (and its handler).
If you contribute through the plugin.xml, then you only have one
handler but you depend on variable sources (activePart, for example)
or your own data to determine your handlers state, and then you're
back to all visible tool items will reflect that state.
In 3.x you can only get the behaviour you want by providing one
command per view and the matching handler at the Workbench Window
level (as opposed to activating it against the view site
At the workbench window level we record the set of
IEvaluationReferences that apply to that window. When a second window
becomes active we stop processing changes (and for most coolbar items,
they stop changing enabled/disabled). When the first window becomes
active we lift the restriction.
The same pattern could be adapted for the view toolbar items so they
would maintain their last state when their view is not the active
view. That would be an enhancement request.
> I've searched through the bugs a bit and I've only found one reference to
> this problem in bug 180203 comment #11.Â Is there a bug specifically for
> this problem and has it been fixed?
I had a quick look and could not find a bug, although it's been
discussed many times on the forums.
Hi floor. Make me a sammich! - GIR