ClipboardAll() add clear option

[crocodile]

We know that loading the clipboard requires constant attempts because of possible contention, hence the option "#ClipboardTimeout".

And I use "A_Clipboard := ''" after almost all ClipboardAll() to empty the clipboard (for ClipWait), which is a waste because loading the clipboard can be costly.
So I want ClipboardAll() to add empty option to avoid loading clipboard frequently.

[lexikos]

Wut? How will this avoid loading the clipboard? Emptying the clipboard is emptying the clipboard.

Edit: Do you mean opening the clipboard? It should be very unlikely for A_Clipboard := "" to have any trouble opening the clipboard after ClipboardAll() returns, as it would be very unlikely that some other app has been able to open it. Add to that, apps usually only access the clipboard in response to user input, such as the Ctrl+C that you're likely going to send and haven't yet.

I've personally never made use of the clipboard timeout, so maybe I'm underestimating how much of an issue it is; perhaps with apps that use the clipboard in unconventional ways.

You could consider using OnClipboardChange instead of ClipWait. Then you would not need to empty the clipboard at all.

[crocodile]

Thanks for the advice.
My understanding of the two commands is:

ClipboardAll()
{
DllCall("OpenClipboard", "UPtr", A_ScriptHwnd)
; GetClipboardData..
DllCall("CloseClipboard")
}

A_Clipboard := ""
{
DllCall("OpenClipboard", "UPtr", A_ScriptHwnd)
DllCall("EmptyClipboard")
DllCall("CloseClipboard")
}

Frequent OpenClipboard() is a waste.


I have a clipboard history script, and it seems to me that clipboard interference and competition is common. For example, if you copy twice in a row, the second copy may conflict with the script.

[lexikos]

A script can empty the clipboard via DllCall about 8000 times per second on my system, failing about 8 times. A_Clipboard can do it successfully 10000 times per second.

If I take out EmptyClipboard, the script can open and close the clipboard about 860000 times per second. This is less than 1% the time it takes to empty the clipboard when it is already empty. It is less than 1% of 1 millisecond. You are barking up the wrong tree.

[crocodile]

I think we should test harsh environments, not loose. Suppose there are three processes that constantly and randomly read and write to the clipboard over and over again, one process that writes screen pixel data to the clipboard, one process that writes bulky Office documents, and one process that is a clipboard history tool. The results would be completely different.
Following your test methodology, there is absolutely no need for AutoHotkey to create the "#ClipboardTimeout" command.

[iseahound]

That's actually a misconception: most data isn't stored on the clipboard. Instead, when the clipboard is accessed, the data is then rendered by the program. So these delays can be attributed to delayed rendering.

[lexikos]

Crocodile, I think your missing the point.