Community
Participate
Working Groups
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.
MultiEditorInput is not persistable, so it will not be restored on restart. PW
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.
(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.
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.
