Eclipse Community Forums
Forum Search:

Search      Help    Register    Login    Home
Home » Eclipse Projects » Rich Client Platform (RCP) » [commands] Unwanted deactivations of menus
[commands] Unwanted deactivations of menus [message #889321] Tue, 19 June 2012 05:54 Go to next message
Daniel Krügler is currently offline Daniel Krügler
Messages: 853
Registered: July 2009
Senior Member
In our RCP product I try to use commands as much as possible, but I
found that there is at least one situation where actions are still used
because they behave more conveniently here: If we have a view that
contains a tree viewer, typically this view will provide a "collapse
all" action in the view toolbar (a similar example is a "refresh" or
"expand all" action at that location).

Originally I found it astonishing that all these actions are provided as
Actions by the standard Eclipse views (Package Explorer, Navigator, ..),
so I wanted to use the public CollapseAllHandler taking advantage of the
predefined command id "org.eclipse.ui.navigate.collapseAll" via
programmatic activation through the IHandlerService. This works, but it
causes an very obvious visual difference compared to equivalent
contributions provided by Actions: Unless the view is not the currently
active part, the toolbar item will be disabled. This is so, because I
queried the IHandlerService from the view site, therefore this site is
not active when the view is not active. One could try to fix this by
using a "wider"
service locator (like the workbench window site), but that will directly
lead to a handler conflict, if there is a second view that tries to use
the same approach.

I wonder how the effects of actions can be realized with a command-based
approach: This example nicely shows, that from a user's perspective the
tool bar item should be enabled irrespective whether the view is active
or not.

I have not find good alternatives so far, so I'm asking others for their
suggestions.
I'm aware that I could associate a user-defined special command id with
the CollapseAllHandle, but then I have the disadvantage that I cannot
inherit the pre-declared command image (or key binding), so this seems
not like a good solution for me. Accepting the current state (disabled
when view is not active) is also no choice for me: Users complain about
this.

Any ideas?

Thanks & Greetings from Bremen,

Daniel Krügler
Re: [commands] Unwanted deactivations of menus [message #889611 is a reply to message #889321] Tue, 19 June 2012 12:06 Go to previous messageGo to next message
Paul Webster is currently offline Paul Webster
Messages: 6859
Registered: July 2009
Location: Ottawa
Senior Member

The problem you've noticed is related to 3.x and the global application state.

Eclipse4 contains a architectural change that allows the behaviour you want, which is the handler is active within the view, and gets all of its information from the view's local IEclipseContext. The toolbar item in the view will always ask if the collapeAll command can run within the context of the view (so the correct location and the correct information) and won't become disabled when switching to another view.

4.2 uses Eclipse4 to implement the global application state, to it's not quite fixed yet. But hopefully in 4.3 we'll get to address this.

PW


Re: [commands] Unwanted deactivations of menus [message #889625 is a reply to message #889611] Tue, 19 June 2012 12:20 Go to previous message
Daniel Krügler is currently offline Daniel Krügler
Messages: 853
Registered: July 2009
Senior Member
On 2012-06-19 14:06, Paul Webster wrote:
> The problem you've noticed is related to 3.x and the global application
> state.
>
> Eclipse4 contains a architectural change that allows the behaviour you
> want, which is the handler is active within the view, and gets all of
> its information from the view's local IEclipseContext. The toolbar item
> in the view will always ask if the collapeAll command can run within the
> context of the view (so the correct location and the correct
> information) and won't become disabled when switching to another view.
>
> 4.2 uses Eclipse4 to implement the global application state, to it's not
> quite fixed yet. But hopefully in 4.3 we'll get to address this.

Thanks for your response, Paul. Unfortunately we will be bound to use
the Eclipse 3.x API for quite a while. From your reply I conclude that I
need to use actions at those places to realize the wanted effect,
because this is the behaviour that our users do expect.

Greetings from Bremen,

Daniel Krügler
Previous Topic:Switching rcp headless build (ant task) to use target platform
Next Topic:Exporting RCP, compilation errors
Goto Forum:
  


Current Time: Tue Oct 21 21:40:34 GMT 2014

Powered by FUDForum. Page generated in 0.01623 seconds
.:: Contact :: Home ::.

Powered by: FUDforum 3.0.2.
Copyright ©2001-2010 FUDforum Bulletin Board Software