Rob,
This is like digging for gold in ones own backyard! <g> But I
appreciate the help, and I'm sure I track down the right way to deal with
this if I just keep working at it! Brad White sent me a link to some info
on this as well which I am going to check out this morning, so perhaps I'll
get a clue to the problem there.
>From "Robert Meek"
Personal e-mail: [EMAIL PROTECTED]
dba / "Tangentals Design"
Visit us at: www.TangentalsDesign.com
Home of "The Keep"!
Member of: "Association of Shareware Professionals"
Moderator for: "The Delphi", "Delphi-DB", and "Delphi-Talk" programming
lists at elists.org,
and proud to be a donator to the Jedi VCL 3.0.
-----Original Message-----
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf
Of Rob Kennedy
Sent: Thursday, April 14, 2005 4:49 PM
To: Borland's Delphi Discussion List
Subject: Re: WAS: Oh boy...need pointer help...addendum..NOW
ClipBoardsaving!!
Robert Meek wrote:
> 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
_______________________________________________
Delphi mailing list -> [email protected]
http://www.elists.org/mailman/listinfo/delphi
