What goes wrong when you add "Copy To" to the context menu
Lockergnome tipped people off
to
this page which talks (among other things)
about adding "Copy To" to the context menu.
I considered adding this tweak
to Tweak UI but ultimately decided against.
Here's why:
The "Copy to Folder" and "Move to Folder" options weren't
designed to be on the context menu. They were only meant to be
placed in Explorer's toolbar. (Right-click a blank space on
your toolbar, select Customize, and pick "Move To" or "Copy To"
from the list of available buttons.)
If you add them to the context menu, you may notice that the
"Copy To" and "Move To" dialogs start showing up when you
really aren't expecting them, for example, whenever you
double-click an attachment in Outlook.
The reason is that these two items are a bit too eager.
When you ask them, "So do you handle the <X> command?"
they say, "Oh yes! That's me!"
This is fine in a toolbar, where the only time they're
asked "Do you handle the <X> command?" is when the user
clicks on the button. But in a context menu, you are
asked this much more frequently, and with
varying values of X.
So when Outlook launches an attachment, the shell loads up
the context menu handlers and asks each one,
"So do you handle the Open command?"
The "Delete" option says, "Nope, sorry."
So does "Cut" and "Send to" and "Sharing and Security".
But "Copy To" happily says, "Oh yes! That's me!"
And then the Copy To dialog shows up when you don't want it.
Another example of what happens when you take an object
and use it in a situation outside its design parameters.