Rob and Jim,
This afternoon I was finally able to find my copy of the Tomes of
Delphi Win32 API which has been misplaced since I moved here two years ago.
I remembered that it included a chapter on working with the clipboard and so
had been looking for it everywhere. I finally found it stored in with some
of my kids books!
Anyway, after studying how the author makes use of he various
methods provided under the API I began re-writing the code Rob sent, but for
the life of me I couldn't see any real differences except that he had
included no real error checking and used a series of procedures and
functions that broke the code down into more readable ones.
Finally, I pulled the "Win32Check(Data <> 0);" line out of the
loadClipboard procedure because that seemed to be the place that was hanging
with the "Segment already released" error message. And wouldn't you know
it...now it works just fine!
Not only does it now store the default Windows Formats like plain
text, bmp's, filenames, URL's, and whole files, but also any specially
registered ones as well! ( At least I've tested it on rtf, Word .doc
formatting, and a couple graphic formats so far ). And best of all it does
not require re-registering the formats used even between Windows sessions!
So all I have to do now is alter the code a bit to send the filestream to my
Blob field and back again, and add some exception handling that won't
interfere with the API calls!
Thanx much for all your help! I learned more by going over the
details of this problem and it's various solutions with you than I might
have should the code you sent me worked "right out of the box"!
>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 Robert Meek
Sent: Saturday, April 16, 2005 2:05 AM
To: 'Borland's Delphi Discussion List'
Subject: RE: WAS: Oh boy...need pointer
help...addendum..NOWClipBoardsaving!!
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
_______________________________________________
Delphi mailing list -> [email protected]
http://www.elists.org/mailman/listinfo/delphi
