Community
Participate
Working Groups
I am trying to implement IElementUpdater.updateElement() which uses state found in the element's part. I tried to get the IWorkbenchPartSite using the service locator as suggested in UIElement comments, but this doesn't work. It seems that IWorkbenchLocationService was introduced with bug 229127 as a replacement, but it's not an an API yet. Please make this interface public. P.S. Workaround suggestions welcome.
AFAICT that information is only available within in the IWorkbenchLocationService in 3.4. You can use it in 3.4, but would need to use the different (public) API in 3.5 PW
That makes sense, thank you.
I'd like to get this in early in M4. Eric, Boris, I'd like for this to be a simple pattern so that for any given IServiceLocator, you can request this service and you can "find" your location. PW
Paul, what does 'location' mean in this context? (part, site...?)
basically, "what level am I at" and "what workbench model can I see". There are a lot of situations (dynamic menu contribution, service creation) where the client needs to get their workbench window or the part they belong to (we had to do it for our service creation). Before making it public, I'd like to make sure that 1) it works in the current workbench and 2) that it generalizes to the component concept (hierarchy of service locators but not restricted to Workench>Workbench Window>Part) PW
(In reply to comment #5) > Before making it public, I'd like to make sure that 1) it works in the current > workbench and 2) that it generalizes to the component concept (hierarchy of > service locators but not restricted to Workench>Workbench Window>Part) I think it does generalize, but I don't like the idea very much because it ties the consuming code to its context. I would prefer adding a service that makes it possible to do dynamic menu contributions without having to refer to specific objects in the Workbench model.
(In reply to comment #6) > I think it does generalize, but I don't like the idea very much because it ties > the consuming code to its context. Doesn't that make sense if the consuming code acts on its context? In my specific case, I'm trying to implement a handler that modifies the properties of a view that its in.
Maybe I don't understand the use case - Paul, could you try to explain it to me?
This (or some appropriate other answer) will need to go in for M6 Perhaps to be more consistent with what might happen in e4, it should be a lookup service. You give us your Part or PartSite or IServiceLocator and we'll look up your IWorkbenchWindow or IWorkbenchPart PW
(In reply to comment #8) > Maybe I don't understand the use case - Paul, could you try to explain it to > me? I have a use case in bug 246243, which is marked as depending on this one: I am trying to convert some of the JDT actions in debugger views to the command framework. Some of the handlers implement IElementUpdater to set the correct checked state to the UI element. This checked state is calculated using the view part where the command appears. But the UIElement, which is given in the IElementUpdater.updateElement(), only contains the IServiceLocator as its link to the local context...
This will have to be deferred to 3.6, as I am not confident that we can fix bug 267083 decently enough. PW
This bug hasn't had any activity in quite some time. Maybe the problem got resolved, was a duplicate of something else, or became less pressing for some reason - or maybe it's still relevant but just hasn't been looked at yet. If you have further information on the current state of the bug, please add it. The information can be, for example, that the problem still occurs, that you still want the feature, that more information is needed, or that the bug is (for whatever reason) no longer relevant.
