Rob and Jim,
By removing the same Win32 check from the LoadClipboardFromFile
method in Rob's code that I had from the SaveclipboardTofile method, I am
now able to handle all basic Window's registered clipboard formats including
files, pictures, text, etc., which in itself is a great deal better than
what I originally had! Thanx much for the code and help you both gave!
Now comes the specially registered types like doc and/or rtf
formats. As I mentioned earlier, it seems that when ever I attempt to do so
I get an error that the segment has already been discarded and thus cannot
be placed back on the clipboard. I don't wuite understand that since we're
loading the entire segment back directly from the file to stream it was
originally saved to! But I thought upon further investigation that the
reason for this may be that as soon as the segment is discarded, by closing
the app that it was originally copied from and/or copying something else to
the clipboard such as plain text, the format was getting unregistered. So
next I attempted to re-register the format by first using
"IsClipboardFormatAvailable" passing the Format, a cardinal retrieved from
"GetFormatNumber" and then if not, using
RegisterClipboardFormat(PChar(FormatName)) and passing the Formatname
originally saved to the file and converting to a PChar as required. This
did not work as I received the same "Segment has already been discarded"
error message. I also tried just checking if the format was available by
means of a return value < 1 meaning it is not. But again the same error
message!
I haven't been able to find any other means to registering the
format unless I'm passing the parameters incorrectly? But even stranger is
the fact that even if the rtf in WordPad gets saved to the file from the
clipboard properly, and even if I leave it showing in Wordpad, upon
attempting to reload the clipboard from the file I still get the same
"Segment has already been discarded error" message! That means evidently
that as soon as the LoadClipboardFromFile method runs, the code that empties
the clipboard is also obviously discarding the segment as they call it!
Still however there must be a way of doing this because I've seen utility
apps that handle this very well. Any ideas as to how this is to be
accomplished?
>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
