I managed to trace thru the code example you sent me and found that the error was occurring ONLY when anything other than CF_TEXT was being saved to a file, and that I could get around the error by eliminating the Win32 check. These lines I commented out and the multiple formats were then read and written correctly. I confirmed this by adding a stringlist and adding each of the enumerated formats to it and then saving it to a separate, readable file.
//Win32Check(Data <> 0); //Assert(Format = 0); //if GetLastError <> Error_Success then RaiseLastOSError; // Use 0 to designate end of data
Only the first of those lines should have caused any problems.
I cannot say why this was causing the Win32 OS call failed error but perhaps you can?
The exception occurs in RaiseLastOSError, but you can determine which line of my code triggered the exception by looking at the call stack.
Still however, upon attempting to load the stored file back to a stream and then the Clipboard I would again receive an error unless it was CF_TEXT. This time the error stated that the "Segment has already been discarded and cannot be locked!"
Right. That comes from trying to call GlobalLock on a memory handle that refers to a zero-byte buffer. GlobalLock returns nil, which I assumed could only happen when an error occured. (MSDN suggests as much.) When you GlobalAlloc zero bytes, GlobalLock returns nil even though it's not really an error.
When an API function succeeds, the result of GetLastError will often be undefined. In this case, the OS might have called SetLastError prospectively, in preparation for the "discarded segment" error that never happened.
-- Rob
_______________________________________________ Delphi mailing list -> [email protected] http://www.elists.org/mailman/listinfo/delphi
