Eclipse Community Forums: Eclipse Platform » Conditional Enablement for Handlers on a Workbench Part

Help

Home

Home » Eclipse Projects » Eclipse Platform » Conditional Enablement for Handlers on a Workbench Part

Show: Today's Messages :: Show Polls :: Message Navigator

Conditional Enablement for Handlers on a Workbench Part [message #327052]

Mon, 07 April 2008 18:37

Stuart Pond

Messages: 27
Registered: July 2009

Junior Member

I am providing a custom handler for the Save Command in my RCP application
that is only active when a particular ViewPart is Active. I would like the
handler's enablement (Gray/UnGray) to be attached to ViewPart's dirty status
since the ViewPart implements the ISaveablePart interface. I would like all
the Save commands menus/toolbars to update imediately when the ViewPart's
dirty status changes, so something (I guess my handler) is going to have to
be listener to up the ISaveablePart interface.

I know the Eclipse IDE must do this already. Does anyone know what needs to
happen here to make this happen?

By the way I am using Eclipse 3.3 and no I can not move to Eclipse 3.4mX for
in the short term.

-Stu Pond

Report message to a moderator

Re: Conditional Enablement for Handlers on a Workbench Part [message #327053 is a reply to message #327052]

Mon, 07 April 2008 19:24

Paul Webster

Messages: 6859
Registered: July 2009
Location: Ottawa

Senior Member

Stuart Pond wrote:
> I am providing a custom handler for the Save Command in my RCP application
> that is only active when a particular ViewPart is Active. I would like the
> handler's enablement (Gray/UnGray) to be attached to ViewPart's dirty status
> since the ViewPart implements the ISaveablePart interface. I would like all
> the Save commands menus/toolbars to update imediately when the ViewPart's
> dirty status changes, so something (I guess my handler) is going to have to
> be listener to up the ISaveablePart interface.

Save is not a retargetable action in 3.3. The was Save works is your
part (which implements ISaveablePart/2) fires a property change event
when its dirty state changes and then responds to the the doSave(*)
method when called by the save framework. The SaveAction tracks which
parts fire events and respond true to isDirty()

PW

--
Paul Webster
http://wiki.eclipse.org/Platform_Command_Framework
http://wiki.eclipse.org/Command_Core_Expressions
http://wiki.eclipse.org/Menu_Contributions
http://wiki.eclipse.org/Menus_Extension_Mapping
http://help.eclipse.org/help33/index.jsp?topic=/org.eclipse. platform.doc.isv/guide/workbench.htm

Paul Webster
http://wiki.eclipse.org/Platform_Command_Framework
http://wiki.eclipse.org/Command_Core_Expressions
http://wiki.eclipse.org/Menu_Contributions

Report message to a moderator

Re: Conditional Enablement for Handlers on a Workbench Part [message #327054 is a reply to message #327053]

Mon, 07 April 2008 20:28

Stuart Pond

Messages: 27
Registered: July 2009

Junior Member

Paul,

Thanks for the quick reply. But that was not my question. I have an RCP
application that has its own Save Contribution with its own Save Command
that I want to tie the enablement state to a paticular ViewPart's dirty
state.

Should I do this with a property tester? (did this but it only gets fired
when the activePart changes so it completely misses the dirty state change)

Should I override isEnabled() on my handler?

Should I tell my view to get the saveCommand from the command service and
tell it to refresh?

"Paul Webster" <pwebster@ca.ibm.com> wrote in message
news:ftds35$lol$1@build.eclipse.org...
> Stuart Pond wrote:
>> I am providing a custom handler for the Save Command in my RCP
>> application that is only active when a particular ViewPart is Active. I
>> would like the handler's enablement (Gray/UnGray) to be attached to
>> ViewPart's dirty status since the ViewPart implements the ISaveablePart
>> interface. I would like all the Save commands menus/toolbars to update
>> imediately when the ViewPart's dirty status changes, so something (I
>> guess my handler) is going to have to be listener to up the ISaveablePart
>> interface.
>
> Save is not a retargetable action in 3.3. The was Save works is your part
> (which implements ISaveablePart/2) fires a property change event when its
> dirty state changes and then responds to the the doSave(*) method when
> called by the save framework. The SaveAction tracks which parts fire
> events and respond true to isDirty()
>
> PW
>
>
> --
> Paul Webster
> http://wiki.eclipse.org/Platform_Command_Framework
> http://wiki.eclipse.org/Command_Core_Expressions
> http://wiki.eclipse.org/Menu_Contributions
> http://wiki.eclipse.org/Menus_Extension_Mapping
> http://help.eclipse.org/help33/index.jsp?topic=/org.eclipse. platform.doc.isv/guide/workbench.htm

Report message to a moderator

Re: Conditional Enablement for Handlers on a Workbench Part [message #327075 is a reply to message #327054]

Tue, 08 April 2008 16:47

Paul Webster

Messages: 6859
Registered: July 2009
Location: Ottawa

Senior Member

Stuart Pond wrote:
> Paul,
>
> Thanks for the quick reply. But that was not my question. I have an RCP
> application that has its own Save Contribution with its own Save Command
> that I want to tie the enablement state to a paticular ViewPart's dirty
> state.

Ah, OK, that will be outside of the framework save lifecycle.

> Should I do this with a property tester? (did this but it only gets fired
> when the activePart changes so it completely misses the dirty state change)

In 3.3 property testers (which aren't listening for anything) are only
updated when some known variable (like the activePart) changes. In 3.4
you can request a property be re-evaluated using IEvaluationService
(when the active part fires a PROP_DIRTY, for example).

> Should I override isEnabled() on my handler?

This will work in 3.3, once your handler has been instantiated ... you
will have to make sure you track the active part, listening for part
property changes like PROP_DIRTY ... and remove yourself as a part
listener on every part lifecycle/close event (IPartListener2).

In 3.4, every framework request to check enabled state calls
setEnabled(*) before calling isEnabled(), which allows you to extract
the active part. Although this might not be that helpful, since you
need to make sure that your handler knows about part closings so it can
remove itself as a listener.

> Should I tell my view to get the saveCommand from the command service and
> tell it to refresh?

This is the hardest to do in 3.3. You might be able to get the command
and call getHandler() on it ... but that would most likely return a
HandlerProxy (internal class) for plugin.xml contributions.

PW

--
Paul Webster
http://wiki.eclipse.org/Platform_Command_Framework
http://wiki.eclipse.org/Command_Core_Expressions
http://wiki.eclipse.org/Menu_Contributions
http://wiki.eclipse.org/Menus_Extension_Mapping
http://help.eclipse.org/help33/index.jsp?topic=/org.eclipse. platform.doc.isv/guide/workbench.htm

Paul Webster
http://wiki.eclipse.org/Platform_Command_Framework
http://wiki.eclipse.org/Command_Core_Expressions
http://wiki.eclipse.org/Menu_Contributions

Report message to a moderator

Previous Topic:	CommonNavigator versus TreeView to display entitys from a remote database?
Next Topic:	plugin, ITokenScanner, nextToken --> SWT BUG

Goto Forum:

-=] Back to Top [=-

[ Syndicate this forum (XML) ] [

]

Current Time: Tue Jul 16 08:12:04 GMT 2024

.:: Contact :: Home ::.

Breadcrumbs

Sign up to our Newsletter