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
AdmID:268FDD61EFFA373214C1A8E7398E7E84
_______________________________________________ Delphi mailing list -> [email protected] http://www.elists.org/mailman/listinfo/delphi
