Community
Participate
Working Groups
The MultiPageEditorPart does not provide access to the editor page in use. Plugins that attach special behavior to an ITextEditor will do so by asking the Workbench for the active Editor. If that editor is an ITextEditor, the plugin can be attached. However, if that editor is a MultiPageEditorPart, there is no way to access the actual editor being used to see if it is an ITextEditor. A remedy would be to either allow MultiPageEditorPart to adapt to the active editor page type or, better yet, expose the getActiveEditor() method in MultiPageEditorPart as public. The plugin that spawns this report is the viPlugin, which adds vi functionality to ITextEditors in Eclipse. It does not work with the manifest editors (plugin.xml, feature.xml) because when it asks for the active editor, it receives a MultiPageEditorPart and then has no way to investigate further if the active editor page is an ITextEditor. Ideally, the viPlugin should be able to ask the MultiPageEditorPart for its active editor with multiPageEditorPart.getActiveEditor(). Please either expose MultiPageEditorPart.getActiveEditor() or add adapter functionality similar to below. Thank you. -- tBs public Object getAdapter(Class adapter) { if(ITextEditor.class.equals(adapter) || IEditorPart.class.equals(adapter)) { if(getActiveEditor() instanceof ITextEditor) return getActiveEditor(); if(getActiveEditor() instanceof IAdaptable) { return ((IAdaptable)(getActiveEditor())).getAdapter (ITextEditor.class); } } return super.getAdapter(adapter); }
Exposing getActiveEditor() alone is not enough. Clients also need to be able to register a "page listener" which notifies them on page activation events (similar to the way a part listener notifies on part activation events).
As author of the viPlugin I'm directly affected by this API problem. I'm currently reflecting the method and disable the access control to get what I need, which is the second ugly hack to make something like a viPlugin possible. A listener would be needed too, that is true, otherwise I wouldn't find out that the current active page of the MultiPart has changed. Has it already been considered to open the API at these points? Thx, Michael Bartl
This is a hot topic of debate right now. See Bug 53700 and Bug 46207.
Moving Dougs bugs
As per http://wiki.eclipse.org/Platform_UI/Bug_Triage_Change_2009
Remy is now responsible for watching the [EditorMgmt] component area.
(In reply to comment #0) > Please either expose MultiPageEditorPart.getActiveEditor() or add adapter > functionality getAdapter(Class) was added to MPEP in in 3.2. Is the viPlugin working properly now? (In reply to comment #1) > Exposing getActiveEditor() alone is not enough. Clients also need to be able to > register a "page listener" which notifies them on page activation events > (similar to the way a part listener notifies on part activation events). We added listeners in 3.5, see bug 201391.
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.
