Community
Participate
Working Groups
Release 2.0 I obtained an instance of the Java Editor in the documented way... I have an IFile that points to a .java file. ICompilationUnit cu = JavaCore.createCompilationUnitFrom(javaIFile); IEditorPart javaEditor = javaUI.openInEditor(cu); So far so good. Then in my MultiPageEditorPart I call addPage(javaEditor, input); That's when it hits the fan. Somewhere inside the CompilationUnitEditor, setTitleImage() is called. This fires a property change (IWorkbenchPart.PROP_TITLE) Then the platform calls org.eclipse.ui.internal.EditorWorkbook.updateEditorTab (IEditorPart part). The first line of this method calls getSite() on the IEditorPart and casts the return value to (EditorSite). The only problem with this is that the returned site, in this case, is NOT an EditorSite but a MultiPageEditorSite. A ClassCastException happens. Perhaps this is all in vain because the JavaEditor was never intended to be used as part of a multi-page editor???
The problem is that openInEditor not only instantiates the editor, but actually opens it as a regular top-level editor. Then you're trying to add it as a page inside a MultiPageEditorPart, which is also a top-level editor. So the editor's site gets bashed with the MultiPageEditorSite. The workbench's assumption that the site is an EditorSite is reasonable, since it creates the site for all top-level editors. You will need separate API from JDT-UI to create an editor without actually opening it. You can then add it to the multipage editor. Its site will then only be assigned once, to a MultiPageEditorSite, and the site of the top-level MultiPageEditor will be an EditorSite. You will also need to provide your own EditorActionBarContributor for your subclass of MultiPageEditorPart. It will probably need to delegate to the Java editor's EditorActionBarContributor when that page is active, so you will need API for that as well. Moving to JDT for consideration of these APIs.
Nick, what you describe in comment 1 is essential the goal of bug 71125 right?
Or in better words: it's the goal of bug 71125 to make this work seamlessly for all kinds of views and editors without doing what's suggested in comment 1.
I assume that at the end to make it correctly work we would duplicate lots of work started for bug 71125.
Yes, bug 71125 is for making it possible to nest parts inside each other. Note however that this work is not on the plan for 3.2.
*** Bug 40282 has been marked as a duplicate of this bug. ***
I believe that many of the scenarios for editor nesting not only require the ability to nest an editor (as it normally appears at top level) inside some other editor, but also require some form of customization of the editor such as: - removing or adding actions or customizing their behaviour - having a custom presentation (e.g. showing only source for a specific method) - hardwiring configurations (e.g. force folding off) These would all require extra support even if we did have the supporting infrastructure for general part nesting. It's hard to know exactly what is required without more details about the concrete scenarios in this request and its dups.
Hi, I'm working on a similar problem and wanted to chime in on this. We have most of the menu bar actions working correctly by having our editor's action bar contributor delegate to a CompilationUnitEditorActionContributor, but there are still a handful of things that don't work right. One category of things is the set of functionality that uses the SelectionListenerWithASTManager and ASTProvider classes. These classes ultimately cache and send events related to an AST built on the contents of the current editor. The problem is that they no-op if the current editor is not a JavaEditor. I can't use the same id as the CompilationUnitEditor, because then all java files will use my editor; and I don't think there's a way to say that my editor is "equivalent". Another category of things does an explicit check for the current editor being an ITextEditor, or one of its extensions. (for example the JavaAutoIndentStrategy) I could have my multipage editor implement this, and delegate to the CompilationUnitEditor, but I'm not sure if this is safe, since only one page of the multi page editor is actually a text editor. Also we have a use-case where we might want multiple java source tabs, for different files, in the same multi-page editor.
Please consider for 3.4.
There are no plans to copy/duplicate the work that has been started for bug 46207.
Does this mean that the JavaEditor will move into public API? If so, in which version? In order to pass RFRS by Instantiations WindowBuilder product we should exclude the usage of internal API, but the key feature of WindowBuilder is the multipage editor (java editor <-> designer editor) and it can't be impelemented using public API. Now we are using the org.eclipse.jdt.internal.ui.javaeditor.CompilationUnitEditor class as the base class of multipage editor.
>Does this mean that the JavaEditor will move into public API? If so, in which >version? 4.0. Most likely you will be able to nest the part via ID. For now you have to stick to internal code or create your own page using a SourceViewer with JavaSourceViewerConfiguration.
