Community
Participate
Working Groups
I was wondering why my part was becoming active when I noticed the two lines of code below in CPR... parentContext.set(IContextConstants.ACTIVE_CHILD, localContext); activate(element); This eager activation is in direct conflict with the 3.x IWorkbenchPage's showView method with a IWorkbenchPage.VIEW_CREATE mode passed in.
We should revisit any code that is calling 'activate' to separate activation from the rendering completely (i.e. the rendering engine should not be making the decision on what's 'active' since that's essentially a context oriented operation. One scenario we should consider is the difference between the user clicking on a tab versus the stack's 'activeChild' being set. In the click case we likely want the part activated but not necessarily so for the 'bring to top' case.
Eric, I suggest we pull this code out (the two lines specified in comment 0) for M3, any objections?
Not at all..;-)
Removing the two lines can cause an infinite loop because the window context thinks itself is the active child (not too sure how this happened). Uncommenting line 55 in LazyStackRenderer seems to fix the problem though the proper fix would probably be to add activation code for when the tab has been selected per what's been suggested in comment 1.
(In reply to comment #4) > Removing the two lines can cause an infinite loop because the window context > thinks itself is the active child (not too sure how this happened). May be caused by bug 299195.
Created attachment 156965 [details] ContributedPartRenderer patch v1 This bug is making it difficult for me to implement the compatibility layer as I need to be able to show parts without activating them.
Created attachment 157149 [details] ContributedPartRenderer patch v2 Changed StackRenderer to pick the part that's being shown instead of the first child.
(In reply to comment #7) > Created an attachment (id=157149) [details] > ContributedPartRenderer patch v2 Patch released to HEAD.
