What happens when applications try to copy text by sending Ctrl+C

I'm stealing this story from one of my colleagues.

I remember one app from a long time ago that had a feature where you could hit a global short cut key (or something like that) to launch the dictionary. It was also smart in that it would detect the current selected text and immediately search the dictionary for that term.

One day I was running a Perl script that took several hours to run. It was nearly done and for whatever I decided to launch the dictionary. It sent a Ctrl+C to my Perl script and killed it.

And that's why you don't send Ctrl+C to arbitrary applications.

Active Accessibility gives you access to the text under the cursor. There's also a newer interface known as UI Automation which has a handy method called IText­Provider::Get­Selection. (On the managed side, you have System.Windows.Automation.Text­Pattern.Get­Selection.)

Update: Commenter parkrrrr points out the IText­Provider::Get­Selection. is the provider-side interface. The interface for applications wishing to read the selected text is IUI­Automation­Text­Pattern.

Comments (20)
  1. Robert Morris says:

    Sooo … the correct solution is to send Ctrl+Insert instead, right? ;) </sarcasm>

  2. Mike Caron says:

    It's unfortunate that we've ended up with a commonly-used system where programs can choose what behaviour any given key combination does in the context of its own windows.

    And, don't even get me started on sending WM_USER messages. Why should it be application defined either?

  3. Joshua Ganes says:

    It is very easy to get caught by memorizing keyboard sequences. From time to time, I get up to a lot of text editing using vim. When I return to using Windows text editors, I tend to leave a lot of ":w" sequences in my text files.

  4. Joshua says:

    Yeah, don't send ^C to console windows. There's no guarantee what that's going to do except it's probably not what you want.

  5. parkrrrr says:

    ITextProvider is a provider-side interface; it basically only exists within the process that hosts the control. What you want for this purpose is IUIAutomationTextPattern, which is the client-side unmanaged interface.

  6. Sven Groot says:

    @Joshua: I can sympathize with that. I press CTRL-X, CTRL-S in Visual Studio all the time after I've spent a day in PuTTY using emacs. Speaking of PuTTY, I use it so much more often than the Windows console host that I always keep expecting text to get copied when it's selected in the console, forgetting about the extra right click you have to do in the Windows console.

    I remember back in the 90s when, after two hours of coding in QuickBASIC, I accidentally hit the hotkey that caused a TSR used by our printer to pop up its configuration dialog. This hung the entire machine, and I hadn't saved my code at all while I was working. This is the disadvantage of having an development environment that can execute your code without having to save it. ;)

  7. jim steele says:

    Microsoft Bookshelf 2000 does this every time you start it or switch to it.

  8. Gabe says:

    My first instinct would be to send WM_COPY to the window with focus. Why is that wrong?

  9. Tim says:

    Because the clipboard is for the use of the end-user, not for programs.

  10. Leo Davidson says:

    It's unfortunate that we've ended up with a commonly-used system hotkey that does something harmless* half the time and something destructive the other half, depending on which type of app/window with focus.

    (*Nitpick: Okay, that's also destructive if you wanted to keep whatever was in the clipboard.)

  11. MikeBMcL says:

    When I was using Emacs a lot, I found it best to remap Ctrl-X in Visual Studio to avoid removing a line and then saving the file. There are also the Emacs-style keyboard commands, but when those stopped existing in the first release of VS2010 (they've since been added back as an extension: blogs.msdn.com/…/emacs-emulation-extension-now-available.aspx ), I switched to C# 2005 style and just remapped Ctrl-X (and Ctrl-A) to avoid force of habit issues (though I've since restored them both to default since I've broken those finger habits).

  12. Eric says:

    If more apps implemented ITextProvider, more services would use it.  Seriously, how many apps implement ITextProvider today?  I'd be surprised if I needed more than two hands to count them.

    When I was writing an app to do this sort of thing, I had several strategies (because even ctl-C doesn't work everywhere).  I'd *try* UI Automation, but it basically only worked on one or two apps; Internet Explorer had some custom stuff, as did Adobe Reader; but in general, if it wasn't a console window, it was Ctrl-C or nothing.

  13. Rob says:

    I definitely prefer SUPER+C for copying text in text mode(like on OSX, cmd+c).

    On Linux though, you've got two different clipboards(The X11 cutbuffer and a separate clipboard that GTK/QT applications use.)

    GTK/QT applications have the behavior of Windows(ctrl+c), but the X11 cutbuffer works by copying text on highlight.

    Probably the worst idea ever ;-)

    I'd definitely prefer the behavior of Windows, ctrl+c, over the two clipboards you'll see on Linux, but SUPER+C is the best solution for me.

  14. Worf says:

    It's one of the reasons why Ia standardized on text editors throughout my computing career. I use Vim, and practically every playform has a version. It's wonderful on Windows (and yes, I get :w strewn when some other editor pops up…).

    Worst habit is apps that close windows on Esc. Can't tell you how many times that messed me up.

    The one big difference in vim behaviour is visual block mode – Ctrl-V on all platforms except Windows (Ctrl-Q), because Ctrl-V means paste.

  15. Adrian says:

    I've never managed to get MSAA or UI Automation working with many types of application. Java needs the Java Access Bridge which is poorly maintained. SAP requires a scripting interface that must be manually enabled in the client first. Firefox technically supports IAccessible2 which shares much with MSAA but still needs special code. Chrome currently is a black box.

  16. Bug says:

    Messages are often lost with posting on this blog, there's a repeatable bug in this blog software. Plase fix it, or change it´all together.

  17. Skyborne says:

    @Worf – there's a way to set that. I have my windows gvim configured so Ctrl-V starts visual block mode, but I'm not sure how I did it.  It's not anywhere in my _vimrc, so I suspect I edited a :behave mswin out of the standard startup scripts somewhere.

    @Bug – MS has probably filed a ticket with the blog software vendor already. In any case, it's not within Raymond's power to singlehandedly fix it, in spite of his awesomeness.

  18. Adam Rosenfield says:

    I also often hit Ctrl-X Ctrl-S in Windows applications, which usually isn't catastrophic (Ctrl-Z and source control for the win), and I also often find myself just Ctrl-S in emacs after working in Windows apps for a while, which is rather harmless (incremental forward search).

    @Bug: It tends to happen if you take a long time in between starting to write your comment and submitting your comment.  Yes, it's annoying, but it's beyond Raymond's control.  To be safe, you can copy+paste your comment into another application before submitting.  Once I forgot to do that with a rather long comment, and to avoid retyping it, I hooked up Wireshark, hit F5 to refresh the page and attempt to resubmit the POST, which the blog didn't accept, but at least I was able to grab the comment from the Wireshark capture.

  19. David Ching says:

    @Eric – I agree, when driving 3rd party apps, it's rare they implement the appropriate automation/accessibility API's that are preferable, and Ctrl+C is the only way to get their selections (short of on-screen OCR).  Still, it is distasteful and dangerous to do so on arbitrary apps, so if your app is going to do this, better let the user select which apps to do it for and don't do it if another app has the foreground.

Comments are closed.

Skip to main content