| Conditional Enablement for Handlers on a Workbench Part [message #327052] |
Mon, 07 April 2008 14:37  |
Eclipse User |
|
|
|
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
|
|
|
|
|
| Re: Conditional Enablement for Handlers on a Workbench Part [message #327075 is a reply to message #327054] |
Tue, 08 April 2008 12:47  |
| Eclipse User |
|
|
|
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
|
|
|
Powered by
FUDForum. Page generated in 0.03426 seconds
Home