SyntaxEditor has a serious delay in executing the cut command on Windows 11!

SyntaxEditor for WPF Forum

Posted 2 years ago by Sunshine - Appeon
Version: 22.1.1
Platform: .NET 6.0
Environment: Windows 11 (64-bit)

Platfrom: .NET 6.0

Environment: Windows 11 64-bit


Host Name:                 xxxx
OS Name:                   Microsoft Windows 11 Enterprise
OS Version:                10.0.22000 N/A Build 22000
OS Manufacturer:           Microsoft Corporation
OS Configuration:          Standalone Workstation
OS Build Type:             Multiprocessor Free
Registered Organization:
Product ID:                00329-10438-39361-AA146
Original Install Date:     4/20/2022, 6:52:03 AM
System Boot Time:          4/26/2022, 9:23:15 AM
System Manufacturer:       Dell Inc.
System Model:              OptiPlex 5000
System Type:               x64-based PC
Processor(s):              1 Processor(s) Installed.
                           [01]: Intel64 Family 6 Model 151 Stepping 2 GenuineIntel ~2100 Mhz
BIOS Version:              Dell Inc. 1.0.23, 2/23/2022
Boot Device:               \Device\HarddiskVolume1
Input Locale:              en-us;English (United States)
Total Physical Memory:     16,073 MB
Available Physical Memory: 944 MB
Virtual Memory: Max Size:  34,458 MB
Virtual Memory: Available: 4,133 MB
Virtual Memory: In Use:    30,325 MB
Domain:                    WORKGROUP
Hotfix(s):                 3 Hotfix(s) Installed.
                           [01]: KB5012121
                           [02]: KB5012592
                           [03]: KB5011650
Hyper-V Requirements:      A hypervisor has been detected. Features required for Hyper-V will not be displayed.

We have tested it here, and some Windows11 systems will have this phenomenon. Selecting some text in SyntaxEditor and executing ctrl+x will cause a delay of about 1-2 seconds.

Comments (6)

Posted 2 years ago by Actipro Software Support - Cleveland, OH, USA


That's odd, we have not had any reports of that and we run Windows 11 here and have not seen it.  It's cuts instantaneously when I try.  Nothing has changed in the Cut logic in a long time either.

Does it happen only the first time you cut within an application session, or every time?

The main line that accesses the clipboard is this basic one:

Clipboard.SetDataObject(dataObject, true);

Can you use a performance profiler application and try and see what method call is specifically causing the delay?  If you are only seeing it on some Windows 11 machines, this sounds like more of an operating system bug of some sort.

Actipro Software Support

Posted 2 years ago by Sunshine - Appeon

At the beginning, we also suspected the system reason, but it is normal for other tools on the system to perform cutting operations. This problem only occurs on some specific machines.

The way we performed this test was to install the Sample Browser program directly on the target computer and then open the SyntaxEditor-SDI Code Editor (in-line). can reproduce the phenomenon I describe.

Is the version of Win11 you tested the same as the system information we provided, because not all Win11 systems have this problem.

We are also checking the difference between the problem device and the normal device.

Posted 2 years ago by Sunshine - Appeon

Through debugging, we found that executing

Clipboard.SetDataObject(dataObject, true);

will cause an exception:

OpenClipboard Failed (0x800401D0 (CLIPBRD_E_CANT_OPEN))

By searching for relevant information, this seems to be a common clipboard exception in the system. May I ask if we have a retry mechanism internally, so that we will try to clip the content multiple times when it fails, right?

Posted 2 years ago by Sunshine - Appeon

First of all, this problem should be clearly classified as a problem with the system API itself, but we still need to make some optimizations in Editor performance to deal with such scenarios。

Visual Studio seems to be optimized for this kind of scenario, and all Editors that don't feel it at all on the machine in question are affected by this.

I tried to use the interface of Window.Form to call the clipboard and use the retry mechanism of its interface. The test result seems to be ideal, and the user does not feel the problem of obvious delay. So can the current SyntaxEditor be optimized for such scenarios?

System.Windows.Forms.Clipboard.SetDataObject("Text", true, 10, 10);
Posted 2 years ago by Actipro Software Support - Cleveland, OH, USA


You never answered the questions from our previous reply.  Specficially, we would like to know if you only see this happen the first time you copy on these machines, or on every attempt.  And we also would like to see you do a performance profile session to track down the stack trace of where time is spent.

Yes we tried it on Windows 11 build 22000 and didn't see any delay.

We don't currently have a manual retry mechanism on Clipboard.SetDataObject in our code, and are not calling that overload with retry attempt parameters.  However via reflection, we see that overload of SetDataObject that we call does call the retry overload like this:

SetDataObject(data, copy, 10, 100);

So if the clipboard copy is failing each of those 10 attempts, that could pause the application for over a second.  Maybe we should call the specific retry overload but reduce the number of attempts and delay time?  10 attempts seems excessive.  What are your thoughts on ideal arguments to that overload? 

Looking at the WPF version of the Clipboard.SetDataObject logic where they don't offer alternate retry parameters, they hardcode the same thing of 10 attempts with 100ms sleep in between.  They must choose those arguments for a reason in both platforms.  Probably since the clipboard is a shared resource and whatever other app is currently locking the clipboard needs to be given some time to release the lock?  In that regard, maybe it's not a good idea to change the defaults.

On a side note, before we ever call that method, we also do a quick check (only once) like this and store the value for future calls to ensure security access:

var uiPermissionAllClipboard = new UIPermission(UIPermissionClipboard.AllClipboard);

That normally should occur instantly and again, only executes the first time it tries to access the clipboard.

Actipro Software Support

Posted 2 years ago by Sunshine - Appeon


I didn't use the profiler to debug your controls, we can try to collect some profiling data if necessary.

On machines where we can reproduce the problem, this happens every time we do a copy or cut, not the first time.

The latest build of this product (v24.1.1) was released 2 months ago, which was after the last post in this thread.

Add Comment

Please log in to a validated account to post comments.