GP SoftwareTwitter
Opus FAQsManualCommandsObjects

Copy and paste bug using DOpus and Access 2016


I’m having a problem at the moment where I can’t copy and paste from Access 2016 to another application while DOpus is running in the background/system tray. I try coping from tables, forms, anywhere and it will only sometimes copy. I originally thought this was a bug in access 2016, but when I close all instances of DOpus, I can copy and paste again without issue. I really love DOpus, but find this problem frustrating. Is anyone else having the same issue? Is there a fix or work around (besides, closing Dopus everytime I use access 2016)? Any help is appreciated. I have tested this on 4 different computers, all running pretty much the same software and environment.

Systems have:
Dopus 12.2. (Although I have also tried 12.3)
Windows 10 Pro 64 bit (with latest patches).
Latest Office 365 (Access 2016)

There isn’t really a error, so I don’t know what else to provide.


Do you have any Office/Access add-ins installed?

In the past people have reported similar problems that were traced back to add-ins, and the add-in authors were able to fix things (and seemed to know instantly what the likely cause was, surprisingly), but didn’t feed any information back to us so we’re not sure exactly what causes the problem.

Opus itself has no direct interaction with Office or Access at all, for what it’s worth, but will (like many applications) look at the clipboard briefly to see what is in it when the clipboard is changed.


Thank you for your reply and help.
Yes we did have add-ins.
I removed them and we still had the same issue.
I disabled antivirus and anti-spyware.
In fear of the add-ins somehow still being registered or used in our database, I created a new database just for testing purposes.
I didn’t include any add-ins
and had the bare minimum references which access includes by default.
Made a basic table and module.

I tried to copy from the table and it sometimes copied, but not all the time. I tried copying from the module and it seemed to work as expected (copying every time).
I did notice that when looking in the clipboard, the copying that sometimes worked and sometimes didn’t, was a different data type from standard text. Not sure if that might be part of the problem
- arrows are pointing to the different data type).
I even when as far as to setting up a VM (thinking it might be something on our systems), but still had the same issue.
But with all the machines I’ve tested on, if I close all instances of Dopus (including system tray), I can copy and paste with no issue.
Any help is welcome. Looking forward to the next possible fix.


It seems to be a problem MS Office sometimes has with various software. I’m guessing anything that monitors the clipboard may cause problems, and it probably monitors the clipboard as well and does not retry if the clipboard is busy.

How to Fix Copy and Paste Problems Associated with Microsoft Office has some things to try, and also mentions potential conflicts with Remote Desktop, Skype, Internet Explorer, and Visual Studio (all from Microsoft themselves), as well as Acrobat and some other things.

Cannot open Clipboard is about Excel but may still apply. People in there have various solutions, including changing the default printer driver to the XPS one (seems strange, but helped several people who had HP printers), and clearing temp space, as well as disabling add-ins which you’ve already tried.

Clearing the clipboard also seems to help some people, although it is unclear why. (Perhaps some of the Office apps can’t put data on the clipboard if it currently has non-test/bitmap data from another app?)

In terms of things Opus could do differently, we could provide an option to disable our clipboard monitor entirely, but it would also break some key functionality (e.g. ghosting files when you cut them, and updating the Cut/Copy/Paste menu items), so it might be useful for diagnostics but probably wouldn’t be something you would want all the time. We could also try using the basic clipboard API instead of the OLE one, but I’d have to look into that more, and it could be unrelated.

Given there’s no direct interaction between Opus and Office, and Office seems to have similar problems with a lot of software, and is also where the problem is occurring (and it’s not happening in other software), I’m leaning toward this being something Office is doing wrong, but obviously that does not help you solve it much, and Microsoft are unlikely to support you if you ask them for help.

If you try the suggestions in those linked threads and find they still don’t help, we can look at making a special build of Opus that disables some of the clipboard functionality to test some theories. If something helps them we might be able to add a troubleshooting option to allow it to be changed in normal releases, possibly at the cost of breaking certain functionality. (Please also link your account for us to do this.)


Hi Leo.
We encounter similar issues while using DOpus with MS Excel 2016 on Windows 2016 terminal server.
I know that the bug is not on your side but still we use Excel all the time and the users want me to fix this issue, and there's no way to fix it on MS side.. And when I disable DOpus the bug disappears.
So is there a way to completely disable clipboard interactions in DOpus?


Preventing all access to the clipboard isn't really possible, since Opus relies on the clipboard itself in a lot of places, which that would break.

We'll add a new setting which may help in 12.9.2:

New setting, clipboard_change_delay, under Preferences / Miscellaneous / Advanced [Troubleshooting], allows you to tell Opus to delay before checking the clipboard for changes.

This may help avoid problems using the clipboard in certain software (e.g. Microsoft Office, although a lot of other software triggers the same problem in Office, including parts of Windows itself, so YMMV).

The default delay is 100ms; it was effectively 0 in the past.