1
votes

I am extending a AbstractHandler for an event that can be called from different views. What is the recommended way for the handler to find the view or editor that called the event?

HandlerUtil.getActivePart(event) is not returning the view that spawned the event because the active view changed before the event reached the handler. (This is because we have code in a non-UI thread that periodically gathers info and updates a different view which causes the different view to become active.)

This code appears to work, but is it recommended? Could that key or implementation change since it's not really in the api?

public class MyHandler extends AbstractHandler
{
    public Object execute(ExecutionEvent event) throws ExecutionException
    {
        org.eclipse.core.expressions.IEvaluationContext context = (org.eclipse.core.expressions.IEvaluationContext) event.getApplicationContext();
        String myParentContext = context.getVariable("parentContext").toString();

This returned

PartImpl (correct.view.id) Context

One idea might be to use naming conventions for the Handlers so they are not re-used across different views. However, that doesn't cover the case where a view has secondary ids. We need to know the secondary id to find the view and refresh the object after taking actions on it.

1
Yes that string could easily change as it is not part of the API. What do mean by 'parent' view anyway? What is the handler is invoked for the main menu or a key binding when no view is active. - greg-449
By "parent", I meant the active view when the user selected it's menu item or popup spawning the event. By the time the handler is called, the active part has changed. - reysa
Everything uses the HandlerUtil.getActiveXXX code, I'm not sure if there is anything else. Your background thread should not be changing the active part. - greg-449

1 Answers

0
votes

Greg answered the question in the comment above. 

The use case is:

  • A user takes an action on a selection in View1
  • It is a long running job so the handler launches a Job which updates status for that job in View2
  • Job updates View2 frequently using the following to get access to the view
    showView("View2",null,IWorkbenchPage.VIEW_VISIBLE)  
  • Problem:  User takes another action on a new selection in View1, but the handler's getActivePart(event) returns View2 instead of View1    

Greg answered the question with:

Your background thread should not be changing the active part

Solution

  • View1's handler now does the following
    IWorkBenchPart part = HandlerUtil.getActivePart(event)    
    // saved to refresh View1's selection when long running Job is done
    showView("View2",null,IWorkbenchPage.VIEW_VISIBLE)   
    //so user doesn't have to manually show view themselves. It does change the active view to View2  

                                                                      

  • The scheduled Job now does the following
    findView("View2")    
  • Gets access to the view in the background to make status updates
  • When the user takes another action on View1, the handler's getActiveParent(event) returns View1 since taking that action marked View1 as active
  • And findView is not corrupting the active view from the background job, so it all works now.  Thanks Gregg