Community
Participate
Working Groups
build I20030218 If you create a MultiEditor that opens various text editors, the global actions on the Edit menu (copy, cut, paste, undo, etc...) are disabled and the user cannot access them.
This is a bug in WorkbenchPage.getReference(). Should delete the lines: if(pane instanceof MultiEditorInnerPane) { MultiEditorInnerPane innerPane = (MultiEditorInnerPane)pane; return innerPane.getParentPane().getPartReference(); }
Rodrigo, do you need this for 2.1?
It seems we will not need it anymore. We are taking a different approach that does not use the MultiEditor. You can defer this one.
This is still a problem in M200407150800. Checked using the TiledEditor example.
I'm having this exact same problem with the MultiEditor in 3.0.1. The root of the problem lies in the fact that when one of the inner editors is activated, the IPartListener2 implementors receive PartReferences for the outer editor that implements MultiEditor, not to the inner editor that was actually activated/deactivated/etc. The reason for this is indeed because of WorkbenchPage.getReference(IWorkbenchPart) just as Eduardo suggests (because getReference() returns a reference to the outer editor given an inner editor) The actual cause for this bug is because the RetargetActions attempt to connect to the currently activated workbench part whenever a new one gets activated. The RetargetActions created in the ActionFactory are notified of part activations via the IPartService of the IWorkbenchWindow. The IPartService is implemented by the WWinPartService which uses an IPartListener2 to capture part activations from the active IWorkbenchPage. Therefore, whenever an inner editor is activated, the global RetargetActions only see that the outer editor has been activated (which won't have any action handlers) so they will always be disabled.
Created attachment 15362 [details] Patch to 3.0.1 WorkbenchPage i have attached a patch to the WorkbenchPage that fixes this bug for me. The version of the WorkbenchPage that i used to make the patch was from 3.0.1. Please let me know if this patch is acceptable. Thanks.
Another services bug.... Marking as 3.1, so I remember to come back and look at this patch when I have more time.
I don't think I'll have time to look at this for 3.1. Sorry.
Sadly, the WorkbenchPage code has changed a lot since 3.0 and this patch no longer applies.
Just rolled back to 3.0.2 (version 1.154.2.3) and applied the patch. I like the approach this patch takes (the split into getContainerReference() and getReference() isolates those nasty instanceof checks). I think it shouldn't be too hard to use the same technique on the 3.1 version... but I wouldn't want to try it without any regression tests.
Moving Dougs bugs
Adding Nikolay to the cc list.
AbstractMultiEditor does not exhibit problems with global actions (such as cut/copy/paste). I am not 100% certain but if I remember correctly this problem was sitll present with MultiEditor in 3.4. The fix in AbstractMultiEditor, however, which fixes the global actions problem is different from the one described here. Even though there are only 33 references to the getReference() method, and all of them (except for 12 uses in test classes) are concentrated in the o.e.ui.workbench project, getReference() is a public API and I would not advocate changing its behavior. If at all necessary, I would prefer adding a different method with the capability of returning inner editor references.
Remy is now responsible for watching the [EditorMgmt] component area.
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.
