0
votes

We currently have a couple of clients reporting that our copy-to-clipboard functionality in our Delphi XE2 Win32 app isn't working, and pasting into Excel afterwards results in the old clipboard content being pasted.

We are just copying CSV-like text using Clipboard.AsText, and added some debugging to ensure that we weren't getting silent crashes in the routines building up our CSV string. There's no exception handling around it, so any exceptions should just be displayed to the user (nothing reported).

Has anyone encountered anything like this before, and if so what are the best solutions for it? I notice that in C#-land, according to How to handle blocked Clipboard and other oddities the default behaviour there is to retry 10x with a 100ms delay. Unless that behaviour is written into the WinAPI the Delphi wrapper doesn't seem to do this?

I assume that this is a user-machine problem rather than something in our app, though they apparently don't experience this in other software. In-house we have one user that has the first Ctrl-C fail, but the second succeed (fairly reliably), though testing over 5 other machines didn't show anything.

Due to comments on missing code (I didn't put any originally, as there's nothing really there) - pseudocode implementation is

Data := BuildCSVString();
Clipboard.AsText := Data;
StatusBar.Caption := 'Data copied to clipboard';

So not much scope for failure.

Users see the StatusBar GUI update, so the Clipboard routine is running. Reports are that the clipboard remains unchanged, NOT that it is cleared, so the BuildCSVString routine isn't failing and returning '', either.

There's not much scope to build a reproducible bit of code here (otherwise I'd have probably fixed it by now), I was just wondering whether anyone else had come across this and the best way to solve it.

1
Hard to debug without code. That you have an in-house user with reported failures (needing to re-try) sounds like there is indeed an error in your code. Are you sure the code is actually executing in all cases? Maybe you're not catching the keyboard command because of a focus issue - how can we know? Only you can debug your code. I'd start with your reproducible in-house user's problem - set up a remote debug session and see what happens.J...
So what does BuildCSVString(); look like? How do you know it isn't rebuilding an old string?J...
It iterates over a table and builds a CSV. It may as well be a string constant or returning a random set of characters for the sake of this question. I can guarantee that it's not the issue as it works on everyone else's machine, and it's not the sort of code that would work on one machine but not othersMatt Allwood

1 Answers

0
votes

Rule out excel by having the user paste into Notepad immediately after Excel appears to fail. This will tell you whether it's a problem with copying the data, or whether Excel is having trouble pasting the data. Or, if there is a hybrid clipboard issue, where data appears on the clipboard in multiple formats, from different sources (can happen).