🚀 go-pugleaf

"Martin C" <martinc@aol.com> wrote in message
news:3fa2df07@newsgroups.borland.com...

> My only problem here that the dll send these messages to my
> exe while processing other functions, and once the dll message is
> received by the exe, the dll project holds all its running operations
> until all the code under my exe message event finish executing,

Correct.  Especially since you are apparenty using WM_COPYDATA, which *must*
be called via SendMessage(), never PostMessage().  SendMessage() waits until
the message is processed, whereas PostMessage() does not.  This is critical
particular when passing pointers around, to ensure that the passed memory is
still valid by the time the message is eventually processed.

> so is it possible by anyway not to keep the dll wait until all the
> code under my exe message event finish executing.

Only if you dynamically allocate the memory for the string each time, and
then pass the new pointer as a message parameter.  Then you can use
PostMessage() instead of SendMessage() (but not for the WM_COPYDATA
message).  Thus the application could then receive the string when
appropriate without blocking the DLL, the string memory would remain valid
regardless of anything the DLL is doing after sending the message, and the
application would then be responsible for freeing the string after it
receives it.

However, then you get into the issue of mixing memory managers between the
DLL and application.  It is not good design to allocate memory in the DLL
and then make the application free it directly (and vice versa).  Usually,
they will be using different memory managers, and it is not safe to
deallocate memory from one manager that was allocated in another.  Each
manager has its own unique way of managing memory, and frequently include
additional data in allocated memory which it uses later to ensure proper
deallocation of the memory.  In this case, you would then need to export an
additional function from the DLL which the application can call when needed
to free the string memory that was allocated for the message.  That way, the
string memory will be allocate and deallocated by the same memory manager
and no problems arrise.

Alternatively, just have the DLL spawn a separate thread for the purpose of
waiting for the message processing, then you can use SendMessage() without
extra allocation issues, while not blocking the DLL from doing other things
while waiting for the message to be processed.


Gambit