AutoHotkey Community

Hi Folks,

I wrote a hotkey with the following code:
When it gets to the "process text on clipboard" code, it may fail, because, apparently, ClipWait detects text that had already been on the clipboard before the hotkey fired. Furthermore, the contents of the clipboard at the "process text on clipboard" code is what was on the clipboard before the Send ^c. I find this really surprising.

To fix it, I added Clipboard:="" before the Send ^c. I then saw that this matches example #1 at the ClipWait doc and the "Using ClipWait to improve script reliability" example at the Clipboard doc.

Yes, that works, but it shows that Send ^c has not finished putting new text on the clipboard before it falls through to the next statement. This raises the question of how to know when Send ^c has placed ALL of the new text on the clipboard. In other words, when can we be certain that after success from ClipWait (i.e., ErrorLevel=0) that ALL of the new text is there, especially when the Ctrl+c is copying a large amount of text?

Thanks, Joe

have no answer , but use the second parameter > Wait for any data (?) . Also don't know when it's completed ...

Hi garry,
Thanks for the reply. When the second parameter (WaitForAnyData) is 1 (True), it tells ClipWait to be satisfied when ANY data appears on the clipboard. In this case, I'm looking just for text, so I omitted the second param, which is the same as specifying 0 (False), meaning it waits specifically for text. Regards, Joe

That's interesting. Never thought about that scenario, but I could see how it could happen with a large amount of text. I would put a loop in to keep checking until the clipboard contents go a whole second without changing, like this:

boiler wrote:I would put a loop in to keep checking until the clipboard contents go a whole second without changing

Good idea! It's a bit counter to the doc at ClipWait, which says, "It's better to use this command than a loop of your own that checks to see if this clipboard is blank." But checking to see that it has "completed" (same contents after a whole second) is different from simply checking to see that it is not blank...it can be non-blank after some partial text from the Ctrl+c has come into the clipboard but not all of the text.

That said, it seems to me that Send ^c (more generally, any Send) should be an atomic/indivisible operation, i.e., it should be completed before falling through to the next statement.

Anyway, thanks for the work-around idea...much appreciated! Regards, Joe

@boiler, that's a great little script! I have no use for it right now, but I have saved it into the library of things to use when the time is right...

Thanks!

JoeWinograd wrote: ↑

01 Jun 2020, 15:49

That said, it seems to me that Send ^c (more generally, any Send) should be an atomic/indivisible operation, i.e., it should be completed before falling through to the next statement.

I agree. I'm wondering if they didn't foresee what would happen when used with very large amounts of text when they wrote the code for it. Perhaps it's worth posting in Bug Reports, although I suppose it technically does meet the stated function of "Waits until the clipboard contains data." That seems to not really meet the spirit of the command, though, if it doesn't wait until the copy is completed.

submeg wrote: ↑

01 Jun 2020, 18:05

@boiler, that's a great little script! I have no use for it right now, but I have saved it into the library of things to use when the time is right...

Thanks!

Thanks. I've used a variation of that approach to check to see when a program is done updating graphics that take a while to redraw by doing successive screen captures and continue looping until the image is no longer changing for a second or two.

boiler wrote: I'm wondering if they didn't foresee what would happen when used with very large amounts of text when they wrote the code for it.

Maybe, but it could be that AHK is simply doing a Windows API call that runs asynchronously to perform the Send (but I admit to having no idea what's happening under the covers).

That seems to not really meet the spirit of the command, though, if it doesn't wait until the copy is completed.

Exactly!

Regards, Joe