What goes wrong when you add "Copy To" to the context menu

Raymond Chen

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.

0 comments

Discussion is closed.

Feedback usabilla icon