Community
Participate
Working Groups
WinXP, e4 Compatibility Platform 0.9.0.I20090617-1930 Pasting via Ctrl-V on WinXP does not work properly. - copy text into clipboard - Help->Install New Software... - Ctrl-V to paste - nothing appears to happen - cancel the dialog - notice that a snippet has been opened in an editor and the text pasted there.
Susan, Key bindings are not fully functional yet (it may be that these are parameterized commands). As a workaround you might be able to use the context menu instead (I did this for my demo).
yes, I was able to use the context menu. Just wanted to report the problem...
This is a manifestation of a problem with multiple handlers overriding each other. In this case the proper handler would be WidgetMethodHandler:paste. It is properly read and registered with the WorkbenchContext. However, later Eclipse plugins such as Package Explorer contribute their own handlers for the same id: ID: org.eclipse.ui.edit.paste Handle1: WidgetMethodHandler:paste Handle2: ActionHandler: PasteAction (has "enabledWhen") Handle3: Java editor contributes ... ... There are two generic problems with this: 1) handles are stored directly in the context using ID. As such, multiple handles with the same ID will overwirite each other. 2) the "enabledWhen" part gets lost (specific place is LegacyHandlerService.activateHandler() but there is no processing of it in the new code anywhay). So even if handles weren't overwritten in (1), the absence of "enabledWhen" resolution effectively selects the last processed handle, not the one fitting the desired scenario.
It sounds like this should be addressed by bug 283536 PW
(In reply to comment #3) > So even if handles weren't overwritten in (1), the absence of "enabledWhen" > resolution effectively selects the last processed handle, not the one fitting > the desired scenario. > OK, multiple handlers now work through their activeWhen clauses or programmatic expressions to determine which one is really active, a la bug 283536 But there is still work here, as having the dialog as the active shell should remove most of the other handlers. It doesn't ATM because they use the WorkbenchWindowExpression which is not invalidated by a dialog. PW
Created attachment 142335 [details] working with dialogs v01 OK, things worth noting. When executing in a dialog you end up with the MWorkbenchWindow context (the dialog Shell has the WW Shell as a parent). For things like copy, paste, look at org.eclipse.ui.SubActionBars.setGlobalActionHandler(String, IAction). The Java Editor operation actions are being added with LegacyEditorActionBarExpression to the WW context. Handlers added at the window or site level used to be scoped by the slave services on the way up, so this expression would have been ANDed with at least a WorkbenchWindowExpression, possibly an ActivePartExpression as well. With those at least it wouldn't be active, even if it was visible at the WW level. The patch is a work in progress, but there are other "more correct" paths. What about creating a context for a Dialog that was parented off of the Workbench context and was the active child. That would isolate it from all but the workbench level variables. Of course, the WW would need to be set active when the shell became active. PW
Created attachment 142425 [details] Working with dialogs v02 This adds restrictions to the WorkbenchWindow if the LegacyHandlerService can see the IWW. But it also adds a context to each dialog off of the workbench context, so that they cannot see the state of the workbench window. This seems to have brought back CTRL+C/V in commit, in open type, and in the about dialog. PW
Oleg, could you please have a look at patch v02? PW
The patch v02 looks good to me. Cut/Copy/Paste seem to work as expected.
(In reply to comment #7) > Created an attachment (id=142425) [details] > Working with dialogs v02 Released for I20090723-1930 PW
.
