🚀 go-pugleaf

"Boba" <Boba@somewhere.world> wrote:

> disagree.

Then you have not been using WM_COPYDATA very long and don't
know the best way to use it, or else you have been misusing it
all along.  What I describe is common practice amongst all
implementations of WM_COPYDATA That I have ever seen in any
program code I have ever seen, Borland-oriented, Microsoft-
oriented, or otherwise.

> I have not seen the VCL using WM_COPYDATA for
> intreproc.communications; I don't mean it does not.

I can assure you that the VCL does use WM_COPYDATA internally.
That is alos not to say that any other libraries you use in
the app may not be using WM_COPYDATA for their own purposes as
well.

> that's what WPARAM of WM_COPYDATA is for.

Wrong.  That parameter is for identifying the window who is
sending the data.  That is usually not enough to help the
receiver of the data to decide whether it should handle the
message or pass it on for other windows to handle.  Also, in
many cases, wParam is not actually used anyway and is set to 0, which doesn't help at all.  Hense the need to use the
message data's dwData value to pass your unique ID with.

> You can not do this with BCB3: the SetLength method can
> only thruncate a string.

Not true.  That is what the documentation says, but the actual
source code of AnsiString implements expansion as well.  I
have seen the source code for AnsiString in BCB3, and I have
written code under BCB3 that does expand the string memory as
expected, so I know it works fine.

> The WM_COPYDATA message description insists I make a
> copy of the buffer first.

Which is exactly what the code I showed you earlier is doing.
It allocates an AnsiString buffer to the length of the data
and then makes a copy of the data into the allocated memory.
Your code was doing the same thing, but it used a secondary
buffer to do so.  I just took out the extra step, it was not
needed.  The end effect is the same.


Gambit