AutoHotkey Community

[deanhill1971]

I've written my own multiple clipboard code (just like many other people have done). Everything works great for maybe three hours, then I notice that the contents of my multi-clip list isn't changing. I've determined that the OnClipboardChange label is no longer being called.

Below is my code. The FileExist line was used to diagnose this problem. When I suspect a problem, I create the onclipshow.txt file to see if the label is still being called. Sure enough, the msgbox doesn't display. If I refresh my script, the msgbox does start appearing.

The multi-clip code is pretty small, but I include it into my main AHK script. All told, the script is probably 6000-7000 lines.

Has anyone else seen OnClipboardChange stop responding? Does anyone have any thoughts on how I can diagnose this further? Thanks.

[vital]

i had seen the same problem , but i don't know how to diagnose it .

[deanhill1971]

Thanks for the reply. I'm still seeing OnClipbardChange stop responding (way too often).

Unless there is a fix, I'm going to start restructuring my script in the hope it resolves the issue.

[Laszlo]

Does increasing #ClipboardTimeout make a difference? Something like #ClipboardTimeout 2000?

[deanhill1971]

Thanks for the suggestions Laszlo. I used #ClipboardTimeout 2000, but I still see the problem. I'll try setting the timeout to other values, and see what happens.

[deanhill1971]

I moved all my clipboard code into its own script. The OnClipboardChange label does remain active longer in this configuration, but it still stops being called after several hours of using the script.

Unless people have other suggestions, I'm going to stop using AHK as my "clipboard manager".

[urlwolf]

I'd be interested in knowing whether this is a bug, and if it's been fixed.

I use The OnClipboardChange label a lot, and having it stopping working would mean I have to abandon ahk for this project...

Thanks

[deanhill1971]

So far, vital and I have both run across this problem.

If urlwolf or anyone else wants to try and reproduce the problem, then run the script below.

To test, do copies and pastes throughout the day. Every hour or so, do a copy, then press Ctrl+Shift+V to popup the multi-clipboard menu. Make sure the item you just copied is the first item in the list.

If it is not, then you have reproduced that OnClipboardChange is no longer being called. To confirm even further, create a file named c:\temp\onclipshow.txt. Do another copy, and you shouldn't see a message box. Reload the multi-clipboard script. On an initial load, OnClipboardChange always gets called. Because the text file is present, you will see a messagebox popup. Copy another item, and the message box will show again. This proves OnClipboardChange starts working again after reloading the script.

[Laszlo]

The script above does not prove that OnClipboardChange is no longer being called, if the last content of the clipboard is not shown on the top of the Ctrl-Shift-V list. From the MultiClipboardAdd() function you return “if MultiClipboardAllCurr = %MultiClipboardAllTemp%”. These are binary variables, compared as strings. The comparison terminates at the first NUL’s, which can result in equality for very different clipboards.

You could use dll calls for binary comparisons, but I am not sure, if it was necessary, at all.

If you really want to know if OnClipboardChange is no longer called, add these two lines

[deanhill1971]

Laszlo: Good point about my binary comparison. If I ever get OnClipboardChange to work the way I need, I'll research a long-term solution.

Your Traytip code is a good addition. It serves a similar purpose to the code which checks for the existence of the "onclipshow.txt" file.

[deanhill1971]

Laszlo: Actually, the AHK help file says the following about comparing binary ClipboardAll variables. My interpretation is that my comparison will work fine. Your thoughts?

[Laszlo]

You are right, according to the Help your script should work. But the help is not correct.

I did an experiment, with the following script:

[deanhill1971]

I ran your test in Word, but I wrote the clips out to files then did a binary diff. Word creates two different binary clips even if you copy the exact same data twice in a row. Strange, but true.

Running the test in a Notepad yields two binary clips that are identical. Of course, this is a simplistic test since there is no formatting in Notepad.

So, I ran the test again using Internet Explorer. I highlighted the "Advanced Search" hyperlink on the Google home page and copied it twice. I did a diff of the two binary clips, and they were identical. Also, the AHK "=" operator finds them to be identical.

So, AHK seems to work exactly as the help file indicates.

[Laszlo]

Interesting! However, if the same selection might yield different clipboard data in some applications, checking for equality does not always make sense.

The real problem is with the opposite case, which is harder to test. Different clipboards might test to be equal. You could pop up the traytip if equality is detected. Then you can see if it is for real or not. An unexpected equality could look like a dropped OnClipBoard event.

[Guest]

Has anyone figured out the cause of this bug or a workaround yet?

One thing I've discovered when using onClipboardChange specifically with some Citrix Metaframe applications is that the clipboard in citrix and in Windows (which should normally be identical) become desynchronized whenever onClipboard change is called.

I imagine Citrix has some bidirectional clipboard functionality where a change in the citrix apps clipboard resulted in a change in the windows clipboard, and vice versa. Any script I use with onClipboardChange seemed to break that functionality in one direction.

Copying something in windows seemed to have no effect on what was pasted in the the Citrix app; it is only able to paste data that was copied within it's client. Strangely though, something copied within the citrix application still pasted seamlessly in Windows.