Community
Participate
Working Groups
PlatformUI.getWorkbench().getActiveWorkbenchWindow().getActivePage().getActivePart() is NULL while opening a new view from an existing active view. Reproducible Example. -------------------- 1) Create a RCP Mail template plugin project. 2) In the NagivationView.createPartControl method, add the double click listener to open View.java part, as following viewer.addDoubleClickListener(new IDoubleClickListener() { public void doubleClick(DoubleClickEvent event) { try { PlatformUI.getWorkbench().getActiveWorkbenchWindow().getActivePage() .showView(View.ID, "Test", IWorkbenchPage.VIEW_ACTIVATE); } catch (PartInitException e) { e.printStackTrace(); } } }); 3) Run the RCP mail template project in Debug mode and put breakpoint in the first line of View.createPartControl method. 4)When breakpoint is hit, open Expressons view (if not already opened) and evaluate the expression: PlatformUI.getWorkbench().getActiveWorkbenchWindow().getActivePage().getActivePart(). The value is NULL. (The current active part is expected to be NagivationView) Is this a BUG? Best Regards Surya
Moving to Platform UI. I don't think this is a bug though, if your breakpoint is in createPartControl, the view has not been activated yet.
null is a valid value from getActivePart(). We also don't guarantee an active part until initialization of a workbench window is complete. Or are you saying you have a complete window and getActivePart() returns null within the double-click listener? PW
I am opening a view (View.java viewpart) from a navigation view (on double click listener on tree nodes of this view). Since the break point is in createPartControl of View.Java viewpart and the View (View.java) will not be activated yet. Therefore current active part should be Navigation ViewPart from where we are trying to open View (view.java) viewpart. This is how I see in Eclipse Juno and earlier releases i.e. ActivePart is NagivationView (from where request initiated) until target view (View.java viewpart) is open. Note that I get correct PlatformUI.getWorkbench().getActiveWorkbenchWindow().getActivePage() but not .getActivePart()further on. (In reply to comment #1) > Moving to Platform UI. I don't think this is a bug though, if your > breakpoint is in createPartControl, the view has not been activated yet.
*** Bug 414389 has been marked as a duplicate of this bug. ***
While we're creating the part, the EPartService getActivePart() returns the correct MPart, org.eclipse.e4.ui.model.application.ui.basic.impl.PartImpl@a00ba1fe (elementId: z.ex.rcp.mail.view:Test, tags: [View, categoryTag:Other], contributorURI: null) (widget: ContributedPartRenderer$2 {}, renderer: org.eclipse.e4.ui.workbench.renderers.swt.ContributedPartRenderer@96b22d8f, toBeRendered: true, onTop: false, visible: true, containerData: null, accessibilityPhrase: null) (contributionURI: bundleclass://org.eclipse.ui.workbench/org.eclipse.ui.internal.e4.compatibility.CompatibilityView, object: null, context: PartImpl (z.ex.rcp.mail.view:Test) Context, variables: [], label: Message, iconURI: platform:/plugin/z.ex.rcp.mail/icons/sample2.gif, tooltip: null, dirty: false, closeable: true, description: null) But because the part isn't rendered until we return from createPartControl(*), the CompatibilityPart hasn't been associated with the MPart yet, so org.eclipse.ui.internal.WorkbenchPage.getActivePart() returns null. We haven't returned from even instantiating the CompatibilityPart, so we don't have an object to put in there. I'm honestly not sure what to do in this situation. PW
It seems Surya wants getActivePart to return the *previously* active part, not the part being created. I assume there is code somewhere which sets the active part to null when opening a new part, and in the time between that and until the new part is fully created, the active part is null. Surya: See bug 417310 for a workaround (getting the part via IEvaluationContext).
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. -- The automated Eclipse Genie.
In PartServiceImpl#activate, the following steps are executed: 1. Context updates are deferred 2. The activePart is updated to be the new part 3. firePartDeactivated is called for the previous part 4. The new part is brought to top 5. Part history is updated 6. (optional) focus is set to part 7. firePartActivated is called 8. Part activation events are send 9. Context updates are no longer deferred There are two code paths that trigger this: A. Directly calling activate methods on PartService B. Due to context changes on IServiceConstants.ACTIVE_PART (PartService#setPart) In path A, the Context and PartService do not agree on the active part in step 1, which should not be problematic In path B, the Context and PartService do not agree on the active part in steps 3-8, triggering this bug. Also, step 9 will cause path A to be called. Specifically, in step 4, the part is rendered if not rendered already, i.e. createPartControl is called. PlatformUI.getWorkbench().getActiveWorkbenchWindow().getActivePage().getActivePart(), returns a NULL value if the active part is not rendered yet. As a result, getActivePart always return NULL when called in createPartControl. Bug 417310 has a workaround, to get the activePage from the context, which still contains the old value, the context is only updated in step 9. The inconsistency between the context and PartService is introduced by fixes for Bug 402073, see https://git.eclipse.org/r/13056. As fixes I see two directions: 1. Move step 2 after step 4 2. Separate code paths A and B, let path B do steps 2 and 6, this will trigger setPart (path A), which would do the other steps. Special care in needed for step 5 and in switchPerspective.
*** Bug 489384 has been marked as a duplicate of this bug. ***
