Once again we're talking at cross-purposes here Jim! <g> I don't
know why this happens between us so often but I'll take the blame because at
least I KNOW you KNOW what you're taking about. In any case the problem is
that I was not able to find a way to get the actual format in it's string
form. I was only able to read the list of formats and get their integer
aliases. So in order to set the format correctly for reading from and
writing to the clipboard I needed a way to convert from the integer value to
the string constant! So I thought I could load a list with a set of
name=value pairs I could use to programmatically lookup these conversions.
Based on the code Rob sent I realize now this is probably not
necessary, but at the time I write this I thought it was because I couldn't
find a way to access the constant directly!
Still however, Rob's code failed. It seems that it will only read
and write CF_TEXT as it is.
>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 Jim Burns
Sent: Wednesday, April 13, 2005 1:02 PM
To: 'Borland's Delphi Discussion List'
Subject: RE: Oh boy...need pointer help...addendum!
> Reply: All the code I came across used the string constants after
> converting from the integers.
>
> What does "CF_" have to do with anything. So there are a
> number of commonly
> used "numbers" that have been turned into convenient
> constants for us.
> Reply: Perhaps I missed the call to use them directly
> without conversion?
I'm lost, there's no conversion necessary for a constant of any type.
const CF_TEXT = 1;
What else can be said?
> Reply: Yes, and I thought I DID understand it but when I attempted
> dereferencing the pointer I couldn't compile it!
Ok, then, post the offending line or few.
> some thing! I've never really used pointers except where
So much has been said on this over the years, check the archives. I'm sure
you can find simple explanations on the web. But do it, a programmer has no
excuse not to understand pointers over strings or integers. A pointer is
just another variable with its own special attributes like an integer that
holds different ranges of integer values depending on whether it's signed or
unsigned, or a string that has its length at a negative offset and can be
indexed by char.
> you, basically the area I was having problems with is this:
>
> DataBuffer := GlobalLock(Data);
> try
> DataSize := GlobalSize(Data);
> OutFile.Write(DataSize, SizeOf(DataSize));
> OutFile.Write(DataBuffer^, DataSize);
> finally
> GlobalUnlock(Data);
> end;
>
> Also, exactly what is the purpose of the GlobalLock?
Sounds like you're not reading the help on this stuff. If you look at the
help on GlobalAlloc it becomes quickly clear. Depending primarily upon
whether you allocate fixed or movable memory, the actual return from
GlobalAlloc is either a pointer to that memory or a handle to a memory
object. That makes sense doesn't it? If the memory is movable then if
windows hands you an actual pointer to the memory block and then moves it,
what becomes of your pointer? Additionally, when you actually go to use the
memory block, doesn't it make sense that you might not want windows to move
it while you're trying to use it? Thus, GlobalLock, whereby you tell
windows, lock this memory temporarily as I need access to it. Thus, killing
two birds with the same stone, you tell windows you need to lock the movable
memory and in return it takes your object handle and returns to you a real
and valid pointer to the block in question. When you're (temporarily) done,
you call GlobalUnlock so windows is free to move the block if necessary.
Either way, in the end, you get a pointer to the block of data.
As far as the block above, what's the problem?
> Just for simplicity's sake I would probably like to store the
> formats in a separate field.
> What type could I use to store them...as
> TStrings? Is there anyway to make use of them without
> converting them from their integer values first?
Ok, I understand how you're seeing this but I wouldn't use the term
"converting" to describe this situation. The registered formats aren't
"converted." The registration process involves the registrant providing a
string name for the clipboard format and windows accepting this string name
and passing back an id for that name. You really wouldn't say you're
converting from an HWND to a window string if by calling GetWindowText()
would you? The integer format id isn't something you need to save, the
format names may be.
Regards,
------------------------------------------------------------------------
Jim Burns, <mailto:[EMAIL PROTECTED]>
Technology Dynamics
Pearland, Texas USA
281 485-0410 / 281 813-6939
_______________________________________________
Delphi mailing list -> [email protected]
http://www.elists.org/mailman/listinfo/delphi
_______________________________________________
Delphi mailing list -> [email protected]
http://www.elists.org/mailman/listinfo/delphi
