Community
Participate
Working Groups
Using CTRL+C or CTRL+INS on a Text control (SWT) does not perform the clipboard copy operation. Note that this occurs on Text controls that are shown in a workspace view or editor (text controls shown on wizards/dialog boxes behave properly). Cut and Paste keyboard shorcuts work fine. Unbinding the copy command in the "Preferences" -> "General" -> "Keys" options (or changing the "When" condition to "Editing Text") seem to make the copy operation work, however, previous versions of Eclipse i.e. 3.3 had identical key preferences configurations yet the copy command worked on Text controls.
Cut/copy/paste all work in the text editor. Does the editor or the view in question register a copy global action or activate a handler for the copy command? PW
Paul, Thanks for the reply. The problem occurs when using a Text control within a form inside a view or editor. I am able to reproduce the problem using the properties views of the Schema and WSDL editors from the WebTools project. It also occurs in the design view of the WebTools Project XML Editor. I believe these do not register a global action or handler for the copy command (the PDE editor does and there the copy shortcuts work properly). To reproduce the problem: Download and install WTP. In a clean workspace, create the XML Examples project: "New" -> "Examples" -> "XML" -> "Editing and Validating XML files". Open the file XMLExamples/GolfCountryClub/GolfCountryClub.xsd. In the editor design view, right click on the element "GolfCountryClub" and from the context menu select: "Show Properties". In the Properties view, locate the "Name" field and try to copy the text using CTRL+C or CTRL+INS. I thought about registering a global action or handler for the copy command, but given that there seems to be multiple places where the copy shorcuts have stopped working, I thought of bringing this item up just in case it happens to be something at a lower level.
Created attachment 158884 [details] Plugin example The attached file contains a minimalist example that demonstrates how the clipboard operations using the keyboards have stopped working. Once the attached plug-in is incorporated, from the main menu select: "Windows" -> "Show View" -> "Other". In the "Show View" dialog box select: "Clipboard issue" -> "Clipboard Issue Viewer". Once the viewer is visible, try to copy/paste the text in it. It is also possible to reproduce this problem without using WTP or importing the example into the workspace: - Open the "Error Log" view. - In the filter text control type any text. - Try to copy the text that was entered using the keyboard.
(In reply to comment #3) > It is also possible to reproduce this problem without using WTP or importing > the example into the workspace: > - Open the "Error Log" view. > - In the filter text control type any text. > - Try to copy the text that was entered using the keyboard. This is not an example of a problem. The Error log provides a copy handler (that works on its table). Unless they also provide a focus control handler (similar to TextActionHandler) their filter text control will not support copy (as the main Error log handler is used). PW
Paul, Please try the attached example which does not make use of a copy handler.
When this is running, the default copy handler is being consumed by: ParameterizedCommand(Command(org.eclipse.ui.edit.copy,Copy, Copy the selection to the clipboard, Category(org.eclipse.ui.category.edit,Edit,null,true), ActionDelegateHandlerProxy(org.eclipse.team.internal.ccvs.ui.repo.CopyRepositoryNameAction@3ab43ab4,org.eclipse.team.internal.ccvs.ui.repo.CopyRepositoryNameAction), ,,true),null) Tomasz, so you know where CopyRepositoryNameAction is being activated? PW
(In reply to comment #6) > > Tomasz, so you know where CopyRepositoryNameAction is being activated? It's because of this: <action label="%CopyRepositoryNameAction.label" helpContextId="org.eclipse.team.cvs.ui.copy_repository_name_action_context" tooltip="%CopyRepositoryNameAction.tooltip" class="org.eclipse.team.internal.ccvs.ui.repo.CopyRepositoryNameAction" menubarPath="miscGroup" definitionId="org.eclipse.ui.edit.copy" id="org.eclipse.team.ccvs.ui.copyNames"> </action> Investigating (object contributions don't make good commands because they are almost never valid). PW
Created attachment 159341 [details] object contribution handlers v01 An object contribution handler (if it works at all) should only be active while the activeMenuSelection is valid. PW
Released >20100117 PW
Sorry, Paul I had to revert that change since it caused major breakage of existing commands, see bug 303784.
No problem, I'll re-visit this next week. PW
This fix is good. The handler for Show Annotations cannot come from an objectContribution. It currently comes from an actionSet (good) in the Team perspective, but in the Java perspective where the actionSet isn't on by default it comes from an objectContribution, id = org.eclipse.team.ccvs.ui.IFileContributions (bad). You can turn the actionSet on as a work around, but really we need to open a bug against Team/CVS to provide a handler for that action. PW
Paul, it worked before (3.5) are you saying that it was a bug that it worked there?
(In reply to comment #13) > Paul, it worked before (3.5) are you saying that it was a bug that it worked > there? Yes, exactly. The system was allowing *some* objectContributions to bleed through at the same level as a window contribution. But objectContributions are scoped to the active menu selection, the selection provider registered with the menu currently being shown. It hasn't surfaced as a major problem yet because: 1) most of the time, but not always the selection provider registered with the menu is also registered with the window selection service 2) almost no one assigns command ids to object contributions. But that ability was added so the keybindings could show up (although they would be non-functional while the menu itself was up). This problem is the first that really highlights it, because adding the command id for copy causes the bleed-through objectContribution to kill all native copying (it would be similar for paste, cut, select all, or delete). Adding the appropriate handlers is not API, I could delay this fix to M7 and co-ordinate with Team. PW
What worries me a bit is that this change could also "break" other products that worked just fine so far.
(In reply to comment #15) > What worries me a bit is that this change could also "break" other products > that worked just fine so far. You are right if they were depending on the keybindings->objectContribution behaviour those keybindings will stop working (executing through a menu is not effected). However if any plugin (like Team) were to add an objectContribution for a command (like copy :-) with default behaviour, those commands would cease to function. So few objectContributions filled in definitionIds (since they never really accomplished anything) that it hasn't caused a problem, and wasn't noticed with the team objectContributions that did fill in definitionIds because team actions tend to be composite actions that can handle being actions, handlers, action delegates. Team also provides actionSets for these commands that work and would override any errant object contribution when active. While I'm uncomfortable at a change that could possibly effect the downstream consumers, I've talked to Boris and I think that it is important to fix objectContributions and make them work correctly (restrictedly) rather than risk that CTRL+C only works intermittently. PW
The patch has been released to HEAD again, which makes bug 303784 occur again. I assume you left this bug open to remember that you have to add this to the porting guide. AFAIK, the team code has not changed much in that area, so this change likely breaks other similar clients as well. (In reply to comment #12) > You can turn the actionSet on as a work around, but really we need to open a > bug against Team/CVS to provide a handler for that action. I've reopened bug 303784 for that.
> [..] add this to the porting guide. It needs to go into the "Incompatibilities" section. Apart from bug 303784, more actions in the SDK are affected (e.g. key binding for Apply Patch also doesn't work any more unless the action set is enabled).
Created attachment 161870 [details] objectContributions with commandIds in Galileo JEE SR2 I've attached a quick scan of objectContributions from the JEE Galileo SR2 package (because it has a good stack of plugins). Team, Mylyn, and JDT Debug have object contributions with command IDs on them. PW
Created attachment 161908 [details] Incompatibilities section v01 I'll revise and submit after M6 PW
(In reply to comment #20) > Created an attachment (id=161908) [details] [diff] > Incompatibilities section v01 > This does not effect ActionSets It's "affect", see e.g. http://www.merriam-webster.com/video/affectvseffect.htm Given the complexity of the patch for bug 303784, you should also describe how clients can reimplement the condition from the objectContribution in their implementation of IHandler2#setEnabled(Object). (In reply to comment #16) > You are right if they were depending on the keybindings->objectContribution > behaviour those keybindings will stop working (executing through a menu is not > effected). But enablement in menus contributed through "org.eclipse.ui.menus" can be affected, see bug 303784 comment 2.
I've opened bug 306173 to look at other team actions like apply patch and/or commit. PW
>Team, Mylyn, and JDT Debug have object contributions with command IDs on them. Filed bug 306531 for Debug.
Updated with comments and released for I20100520-0800 PW
In I20100520-1744 PW
