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

Hello,

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.

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.

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?

Hi
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);

Hello,

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.

Hi:

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.