Bug 317111

Summary:	[EditorMgmt] Mutipane editor not restored upon workbench startup
Product:	[Eclipse Project] Platform	Reporter:	Samantha Chan <chanskw>
Component:	UI	Assignee:	Prakash Rangaraj <prakash>
Status:	NEW ---	QA Contact:
Severity:	normal
Priority:	P3	CC:	pwebster, remy.suen
Version:	3.6
Target Milestone:	---
Hardware:	PC
OS:	Windows XP
Whiteboard:

Description Samantha Chan

2010-06-16 16:33:42 EDT

1)  Create an multi pane editor implementation based on AbstractMultiEditor.
2)  In my implementation, the multi editor returns a sashform as the main
composite
3)  Each of the sash form contains a view form.  The view form is the parent of
the inner editor.
4)  Start second workbench and open the file that is mapped to the multi pane editor.  I have an editor launcher that "translates" an editor input to a multi editor input, and open the multi pane editor
5)  Restart workbench

Notice that the multi editor is not opened upon workbench restart.

Not sure if I have a way around this if the workbench is not calling my launcher to open the editor.

Comment 1 Paul Webster

2010-06-16 16:43:14 EDT

MultiEditorInput is not persistable, so it will not be restored on restart.

PW

Comment 2 Samantha Chan

2010-06-16 16:55:08 EDT

Can I force it by extending MultiEditorIInput to make it persistable?
But there is a @noextend annotation on the MultiEditorInput class.

Is the only workaround not to use MultiEditorInput, and hence not to use the multi editor support in the platform?  If I am going to use the multi editor as a "regular" editor, am I better off creating my own custom editor?  i.e. duplicating all the code from AbstractMultiEditor?

I can also see that I will end up having to use some internal classes, as I will have to manage the creation of the inner editors.

Comment 3 Remy Suen

2010-06-17 09:26:28 EDT

(In reply to comment #2)
> Can I force it by extending MultiEditorIInput to make it persistable?
> But there is a @noextend annotation on the MultiEditorInput class.

You may be better off illegally extending the class. Though you should make sure all your "sub" editor inputs are persistable, and that you delegate them to appropriately (as necessary) or else the restoration step may be problematic.

> If I am going to use the multi editor as
> a "regular" editor, am I better off creating my own custom editor?  i.e.
> duplicating all the code from AbstractMultiEditor?
> 
> I can also see that I will end up having to use some internal classes, as I
> will have to manage the creation of the inner editors.

Yes, there is quite a bit of code internally to handle AbstractMultiEditors so I'm not sure how far you'll get by making your own variant.

Comment 4 Eclipse Webmaster

2019-09-06 16:13:26 EDT

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.