Comment 1 Nicolas Tavernier 2008-02-27 12:30:08 EST

I'm using eclipse 3.4.0 build I20071101-2000

Once the view has been minimized once, the method getIdForRef(IViewReference ref) of the class org.eclipse.ui.internal.FastViewManager returns true and it should not as the view is not a FastView (the Map idToFastViewsMap contains the view id so the method return true).

Hope it helps...

Comment 2 Eric Moffatt 2009-02-12 11:22:35 EST

First, thanks for the patch! I'm looking at this right now and should be able to come up with something...

Sorry for leaving on the back burner, it was marked 'minor'.

Comment 3 Eric Moffatt 2009-02-12 14:31:08 EST

OK, the basic issue is that once the stack containing the view becomes minimized it effectively becomes a 'fast view'. What this means is that the 'setState' event is being re-routed to the FastViewPane's PartSite. This is incorrect in that that handler expects the fastview to be currently open and it isn't, leading to the NPE.

This is definitely incorrect. Most likely it should direct the state change to the current 'owner' of the part, the TrimStack.

I'm currently trying to find a workaround. Would maximizing/restoring the EditorArea work for you? 

In the given scenario it would behave identically since maximizing the editor area would cause the view stack to minimize. The advantage is that here we're talking to the part that doesn't change into a TrimStack but rather to the one that is still part of the main presentation area.

BTW, this is not going to find its way into a 3.4.x maintenance build (only 'stop ship' defects are considered at this point) so if I need to add code to make this happen it'll only be available in 3.5...

Comment 4 Eric Moffatt 2009-02-12 16:05:59 EST

Created attachment 125582 [details]
Patch to provide a 'setEditorAreaState' API in WorkbenchPage


Apparently there's no existing public (API) mechanism to be able to control the state of the editor area. This precludes RCP applications from writing operations to maximize or restore the editor area.

This patch has an initial (and naive) implementation. For example, it should have a different behavior if the old min/max story is being used (i.e. don't use the upper right stack but the one containing the active editor, if any).

Comment 5 Eric Moffatt 2009-05-06 14:46:46 EDT

*** Bug 274909 has been marked as a duplicate of this bug. ***

Comment 6 Eric Moffatt 2009-05-06 14:50:03 EDT

Marking as major since the code to reproduce this is 'correct' by any sane analysis.

Note that this is unlikely to make it into the 3.5 build since we're in RC lockdown but I'd certainly consider this as a 3.5.1 candidate...

Comment 7 Dave Orme 2009-05-18 11:57:30 EDT

I'm interested in this also

Comment 8 Rob Hayes 2009-05-21 10:13:15 EDT

I managed to work around this problem by essentially finding out how the "restore" button on the fast view pane works..

Basically before trying to restore my view that has been minimized I call the following;
				page.getActivePerspective().getFastViewManager().removeViewReference(<view to restore>, true, true);								

and then call

page.setPartState(<view to restore>,IWorkbenchPage.STATE_RESTORED);

This works for me with no problems other than the fact that most of the calls are to internal Eclipse API, but I'm happy with this until a real fix makes it in to 3.5.1.

Hope this info is useful to someone.

Thanks,

Rob 

Comment 9 Dilton McGowan II 2009-05-21 14:55:05 EDT

(In reply to comment #8)
> I managed to work around this problem by essentially finding out how the
> "restore" button on the fast view pane works..
> 
> Basically before trying to restore my view that has been minimized I call the
> following;
>                                
> page.getActivePerspective().getFastViewManager().removeViewReference(<view to
> restore>, true, true);                                                          
> 
> and then call
> 
> page.setPartState(<view to restore>,IWorkbenchPage.STATE_RESTORED);
> 
> This works for me with no problems other than the fact that most of the calls
> are to internal Eclipse API, but I'm happy with this until a real fix makes it
> in to 3.5.1.
> 
> Hope this info is useful to someone.
> 
> Thanks,
> 
> Rob 
> 

Thanks, sounds like a work-around but I don't see getActivePerspective() off of the active page.

Comment 10 Rob Hayes 2009-05-22 05:36:47 EDT

My fault, I have a local variable with the "page" in it.. anyway the full API call would be 

((WorkbenchPage) PlatformUI.getWorkbench().getActiveWorkbenchWindow().getActivePage()).getActivePerspective().getFastViewManager().removeViewReference(<view to
restore>, true, true);

I've also attached my simple demo to show the workaround.. you only really need to look at the View class.

Comment 11 Rob Hayes 2009-05-22 05:39:18 EDT

Created attachment 136782 [details]
Demonstrates the workaround for restoring views minimized to the fastview pane

Comment 12 Dilton McGowan II 2009-05-22 15:19:12 EDT

(In reply to comment #10)
> My fault, I have a local variable with the "page" in it.. anyway the full API
> call would be 
> 
> ((WorkbenchPage)
> PlatformUI.getWorkbench().getActiveWorkbenchWindow().getActivePage()).getActivePerspective().getFastViewManager().removeViewReference(<view
> to
> restore>, true, true);
> 
> I've also attached my simple demo to show the workaround.. you only really need
> to look at the View class.
> 

Thanks for your efforts. I realized "page" was your variable name. What I'm saying is that on 3.4.1 and 3.4.2, Eclipse tells me that getActivePerspective() is undefined for IWorkbenchPage.

There is a getPerspective() but it does not have getFastViewManager().

Comment 13 Remy Suen 2009-05-22 15:45:01 EDT

reply to comment #12)
> What I'm
> saying is that on 3.4.1 and 3.4.2, Eclipse tells me that getActivePerspective()
> is undefined for IWorkbenchPage.
> 
> There is a getPerspective() but it does not have getFastViewManager().

From comment 10, you can see there is a cast to WorkbenchPage (internal non-API type) and the invocation is not being performed with an IWorkbenchPage (API).

Comment 14 Dilton McGowan II 2009-05-22 17:10:59 EDT

(In reply to comment #13)
> reply to comment #12)
> > What I'm
> > saying is that on 3.4.1 and 3.4.2, Eclipse tells me that getActivePerspective()
> > is undefined for IWorkbenchPage.
> > 
> > There is a getPerspective() but it does not have getFastViewManager().
> 
> From comment 10, you can see there is a cast to WorkbenchPage (internal non-API
> type) and the invocation is not being performed with an IWorkbenchPage (API).
> 

Ah ok I totally missed the cast, now I see. I just tried it and it works great!

Unfortunately it is an internal non-API approach which means I can't use it.

Comment 15 Eric Moffatt 2009-08-06 15:46:55 EDT

I'm tagging this for a try at a fix in 3.5.1...

Comment 16 Eric Moffatt 2009-08-07 11:31:08 EDT

Created attachment 143779 [details]
Patch to allow calling 'setState' on a minimized view reference


If the reference is to a 'true' fast view (i.e. in the FastViewBar) then teh effect is to ensure that the FV is open (to avoid the NPE).

If the reference is to a view in a minimized stack then it will react to the new state this way:

MINIMIZED - No-op (it's already minimized)
RESTORED - restores the stack to the presentation
MAXIMIZED - restores the stack to the presentation and then maximizes it

Note that this behavior manifests even if a minimized (rather than a 'true' fast) view is open. This difference is necessary because we can't 'restore' the FastViewBar.

Comment 17 Eric Moffatt 2009-08-07 11:52:17 EDT

Committed in >20090807. Applied the patch.

Comment 18 Eric Moffatt 2009-08-27 14:53:11 EDT

Verified in M20090826-1100.