I got the opportunity to sit down and actually test the code you sent in your last message to this thread.
Well, that's more than I did. I wrote it and confirmed that it compiled, but I never executed it.
With a simple string copied from Wordpad, there are several formats on the clipboard. The first is DataObject, which appears to be a reference to a COM object since it's only four bytes long. That can't be saved to a file.
The next format is Rich Text Format. After that come a few other variations, with and without embedded objects. Then come the text and Unicode text formats. Eventually, there is the OwnerLink format, which apparently has no data associated with it, so GetClipboardData returns 0. That causes Win32Check to raise an exception. I have no idea why there's no data for that format.
When I skip the offending call to Win32Check, I can cycle through the entire format list, ending with cf_EnhMetafile. That's an odd format; although GetClipboardData returns a valid handle, GlobalLock returns nil, suggesting that Wordpad copied an empty metafile to the clipboard.
Once I have the file, I can then call LoadClipboardFromFile. Once again, OwnerLink and cf_EnhMetafile cause problems, this time because when I try to GlobalLock a handle for a zero-sized buffer, it returns nil, so the Win32Check call fails. If I skip that call, everything works fine.
There were some formats, DataObject in particular, that I don't think are valid once I load them back, but Wordpad appears not to use that format when pasting, even though it's the first format it put onto the clipboard. Since it's the first onto the clipboard, I would have expected that to be Wordpad's prefered format, but apparently not.
As I said, the code I wrote is naive. It doesn't really do anything to handle any special cases, such as formats that aren't appropriate for persistent storage. Also, it should have some provision to handle or ignore the private clipboard formats and the GDI formats, which I think need to be allocated in a different way -- they're freed using DeleteObject, not GlobalFree, so they're probably allocating using functions like CreateFont and CreateBrush.
Unfortunately it seems that it will ONLY handle CF_TEXT. Any other format I try to store in the file causes an "OS function Failed" error. Another odd thing was that in attempting to save RTF via WordPad, I did not shut down the OS at all but did shut down WordPad after saving the clipboard contents first, then I cleared the clipboard out and then attempted to re-load the saved file with the rtf in it and paste it back to WordPad. I received a message that the info had already been cleared.
I cannot reproduce that.
Normally I would only expect this after shutting down and restarting the OS, but even bitmap copies will be retained if the app it was copied from is closed down between copy and paste. The clipboard will usually store the filename of the bmp and I would imagine other info if only a section of it were copied.
The clipboard never holds a file name. When you copy a bitmap from Paint, there might not even *be* a file name. The clipboard instead holds the bitmap object, which is exactly what Paint put onto the clipboard in the first place. Follow along in TClipboard.AssignGraphic and TBitmap.SaveToClipboardFormat to see how a bitmap gets saved to the clipboard.
When you select a file in Windows Explorer and press Ctrl+C to copy the file, even then it isn't just a simple file name that winds up on the clipboard. In that case, it's a special COM object. Copying a file is not the same as copying the contents of a file.
I can much more easily store any CF_TEXT directly into a memoblob with just a few lines of code and don't need to go thru all of this.
Of course. If all you wanted was cf_Text, then you could just have called Clipboard.AsText.
-- Rob
_______________________________________________ Delphi mailing list -> [email protected] http://www.elists.org/mailman/listinfo/delphi
