Bug 48024 - [KeyBindings] Ctrl + C/Ctrl + V doesn't work for files or folders
Summary: [KeyBindings] Ctrl + C/Ctrl + V doesn't work for files or folders
Status: RESOLVED FIXED
Alias: None
Product: Platform
Classification: Eclipse Project
Component: UI (show other bugs)
Version: 3.0   Edit
Hardware: PC Windows XP
: P1 normal (vote)
Target Milestone: 3.0 M6   Edit
Assignee: Chris McLaren CLA
QA Contact:
URL:
Whiteboard:
Keywords:
: 48188 48631 48734 (view as bug list)
Depends on:
Blocks: 48438
  Show dependency tree
 
Reported: 2003-12-03 14:51 EST by Olivier Thomann CLA
Modified: 2003-12-15 14:24 EST (History)
4 users (show)

See Also:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Olivier Thomann CLA 2003-12-03 14:51:34 EST
Using 1203, I cannot use the key bindings (defaults) to copy/paste files or
folders in either the package explorer or the navigator. The corresponding mouse
actions work fine.
Simply Ctrl + C followed by Ctrl + V seems to have no effect.
Comment 1 Douglas Pollock CLA 2003-12-05 13:19:15 EST
Chris, I believe this is another problem with command manager.

The WorkbenchKeyboard determines that "Ctrl+C" is linked to the command
identifier "org.eclipse.ui.edit.copy".  It then asks for the action, and gets
"null" as the response.

If I change WorkbenchKeyboard to allow the event to reach the widget, the copy
still does not occur (i.e., PackageExplorerPart doesn't perform the copy by
listening directly for key events).

This problem has some similarities to Bug 47973 -- fixing one might fix the other.

This problem occurs in both the navigator and package explorer.  Right-clicking
on the file and selecting "Copy" or "Paste" with the mouse works.
Comment 2 Douglas Pollock CLA 2003-12-10 16:05:35 EST
*** Bug 48188 has been marked as a duplicate of this bug. ***
Comment 3 Chris McLaren CLA 2003-12-11 17:01:24 EST
fixed.

(i went down some unfortunately long and painful paths this afternoon.. then i 
was starting at a random open editor for about 10 seconds before i noticed the 
bug right in my face. duh.)

ironically, a copy/paste error itself:
in WorkbenchActionBuilder.makeActions there was the following pair:
	copyAction = ActionFactory.COPY.create(getWindow());
	registerGlobalAction(redoAction);

this was an obvious oversight, but there are a few others in this method that 
are worth a look over.

NICK: newWizardDropDownAction (maybe others?) isn't registering itself at all. 
is this correct?

DOUG: deleteAction's registration is still commented out. i thought at one 
point you were arranging to have the key binding to delete customizable. 
having deleteAction register as a global action would be a prerequisite.
Comment 4 Nick Edgar CLA 2003-12-11 23:21:06 EST
newWizardDropDownAction does not need to be registered.
newWizardAction is the one that gets registered for File > New > Other... 
(bound to Ctrl+N by default).   This is done when in 
WorkbenchActionBuilder.makeActions.

Comment 5 Darin Wright CLA 2003-12-12 09:56:20 EST
*** Bug 48631 has been marked as a duplicate of this bug. ***
Comment 6 Douglas Pollock CLA 2003-12-15 14:24:14 EST
*** Bug 48734 has been marked as a duplicate of this bug. ***