| [Commands] Semantics of IHandlerService.activateHandler [message #655143] |
Fri, 18 February 2011 13:41  |
 Daniel Krügler
Messages: 853
Registered: July 2009 |
Senior Member |
|
|
The specification of the overload
IHandlerActivation activateHandler(String commandId, IHandler handler);
says (emphasis mine):
"If this service was retrieved from the workbench, then this handler
will be active globally. **If the service was retrieved from a nested
component, then the handler will only be active within that component**."
I'm particularly interested in the precise meaning of "active within
that component": What does that mean?
I stumbled across this when I constructed a view which behaves similar
to the Outline view, i.e. it provides dynamically changing contents
based on a "page" concept". Within some some currently active page I
retrieved the IHandlerService from the site of the presenting view, but
all activated handlers behaved like disabled ones (i.e. the menus where
visible, but not enabled). After hours of searching for the cause I
finally tried to use the IHandlerService from the workbench instead,
which worked. This looks like a pity to me, because certainly the active
page is "within" the site of my hosting view.
I would appreciate any hints what's going on here and why I need to use
the global provider - which does not look like a reasonable approach to me.
Thanks & Greetings from Bremen,
Daniel Krügler
|
|
|
|
| Re: [Commands] Semantics of IHandlerService.activateHandler [message #655184 is a reply to message #655156] |
Fri, 18 February 2011 15:11  |
Daniel Krügler
Messages: 853
Registered: July 2009 |
Senior Member |
|
|
On 2011-02-18 15:06, Paul Webster wrote:
> On 02/18/2011 08:41 AM, Daniel Krügler wrote:
>> "If this service was retrieved from the workbench, then this handler
>> will be active globally. **If the service was retrieved from a nested
>> component, then the handler will only be active within that component**."
>
> Perhaps "active within that component" should read "active while that
> component is active".
>
> ex: refresh.
>
> I could activate a handler from the IHandlerService I got from the
> IWorkbenchWindow for each window I open. The handler is considered for
> activation while it's IWorkbenchWindow is active.
>
> I then activate a handler for refresh in the Package Explorer and
> another one in my TobleroneEditor. When the Package Explorer is active,
> its refresh handler is considered for activation (and wins) File>Refresh
> will use that handler. When I activate my TobleroneEditor its refresh
> handler is considered for activation (and wins). File>Refresh will use
> the TobleroneEditor refresh handler.
>
> If I activate a view other than the Package Explorer or TobleroneEditor,
> the the refresh handler from my IWorkbenchWindow is used.
>
> Does that help?
Thanks for your explanations, but unfortunately the problem cause still
remains unclear to me, see below.
> In theory, if you use a PageBookView based view (which provides a
> PageSite) then activating the handler for a page should provide that
> handler as long as the view is active.
I'm indeed using the IPageSite from a view (not a PageBookView, though,
but a view which contains a PageBook) and I also found out that I can
use the workbenchwindow belonging to this site as working
IServicelocator, but the page-site still does not work as service
locator. I noticed that a pre-defined command (e.g restart) does work,
but this does not require manual activation anyway. The problem occurs
when I'm trying to use a handler that is very similar to the pre-defined
CollapseAllHandler and needs manual activateHandler calls.
Could the problem be that I indeed need something like a PageBookView to
realize that? I noticed that this view internally keeps an individual
site per page.
Thanks again,
- Daniel
|
|
|
|
|
Powered by
FUDForum. Page generated in 0.03184 seconds
] 
Search
Help
Register
Login
Home
