Copy to clipboard from RichEdit hangs IDE

-
Copy to clipboard from RichEdit hangs IDE

Could someone check if this happens for you, or it is just me
1. In Windows 10 and Delphi 10.1 drop TRicheEdit on form
2. Run it from IDE add some text to richedit and press Ctrl-C
Application and IDE hangs.

This only happens in Windows 10 (Windows 7 is ok), only when running from IDE and only for TRichEdit

Update: It hangs for ~30 seconds and only first time you press Ctrl-Insert or Ctrl-C.

Comments

  1. Dobrin PetkovAugust 10, 2016 at 10:43 AM

    \sub

    ReplyDelete
  2. Thomas Mueller (dummzeuch)August 10, 2016 at 9:08 PM

    Using any IDE plugins/experts?

    ReplyDelete
  3. Adz BaywesAugust 11, 2016 at 2:07 AM

    Works fine here with GExperts, CnPack, and FixInsight installed

    ReplyDelete
  4. Achim KalwaAugust 11, 2016 at 4:50 AM

    Three days ago, there was very similar question on the JVCL newsgroup (news.delphi-jedi.org). I can confirm the problem on my Windows 10 installation with Delphi 10.1 and a clean, new Delphi registry profile (without any experts, plugins or 3rd-party components) by running "bds.exe -rFoo".

    New VCL application, just put a TRichEdit on the form, run (with debugger!). Type some lines, press Ctrl+A, Ctrl+C (or Ctrl+X). Sometimes - I would say 3 out of 10 times) the application and the IDE will hang for ~30 seconds. And to answer Attila Kovacs: Yes, Ctrl+Insert also make the application hang.

    I have no idea whats going on.

    ReplyDelete
  5. Eugene KotlyarovAugust 11, 2016 at 9:40 AM

    Attila Kovacs
    Yes on Ctrl-Insert too

    ReplyDelete
  6. Eugene KotlyarovAugust 11, 2016 at 9:41 AM

    Thomas Mueller
    I use GExperts only, but I tried uninstalling it and it does not help

    ReplyDelete
  7. Thomas Mueller (dummzeuch)August 11, 2016 at 10:49 AM

    Eugene Kotlyarov I was asking because I noticed that the clipboard expert sometimes raises an exception while trying to access the clipboard. In GExperts that exception is handled, but other plugins might have a bug there. But since you're saying it even happens without any experts... Maybe the IDE itself has similar functionality somewhere. But that's speculation only.

    ReplyDelete
  8. Andreas HausladenAugust 12, 2016 at 7:45 AM

    Let's assume there would be an IDE plugin that watches the clipboard (WM_CLIPBOARDUPDTATE). Let further assume that this plugin uses Clipboard.Open and raises an EClipboardException if another application is putting data into the clipboard for what this other application needs to own the clipboard until it is done. This exception makes it very hard to debug IDE plugins yourself due to the constant exception dialog appearance if you use Copy&Paste. Now assume that this plugin is responsible for this bug because when it calls GetClipboardData the WinAPI function doesn't return until the timeout elapsed.

    Now give that plugin a name: Castalia. Unfortunately you can't disable it because it was "integrated".

    Some tests I did, couldn't reproduce this timeout situation unless it was the IDE itself that caused it. So there must be something else in the IDE/Castalia that causes GetClipboardData to block the (main-)thread.

    ReplyDelete

Post a Comment