🚀 go-pugleaf

Hello

Yes I ended up doing something like this. I even sent a message from the DLL 
to the app to tell it when the PROCESS_DETACH was called so it knew that the 
DLL was no longer in use.

It worked out OK doing this way.

regards
david


"David Pratt" <Prattaratt@sbcglobal.net> wrote in message 
news:4441d664$1@newsgroups.borland.com...
>
> "David" <davids@unite.com.au> wrote in message 
> news:443c5e6a@newsgroups.borland.com...
>>> I still don't understand what David (the op) is trying to achieve.
>>
>> The DLL sends messages to my app but I don't send messages back. If the 
>> user exits the app then I would like to warn the user that there is still 
>> a DLL trying to communicate with it before the user exits. Therefore I 
>> need to know if the DLL is still in use.
>>
>> Actually I do have access to source code for the DLL so maybe I could do 
>> something from the DLL end. I asked here once whether or not you could 
>> send messages to a DLL and it wasn't a simple proposition either.
>>
>> regards
>> david
>>
> Check this out:
>  Since you are already considering re-writing code for the DLL, the 
> DLLMain or DLL EntryPoint (Depends on whether you've selected MFC 
> Compatability  or not) function takes as one of its parameters a reason 
> code, of which one of the valid reason codes for the function to be called 
> is "DLL_PROCESS_DETACH".  I would think you could use this to trap detach 
> calls from apps and display your warning dialog from the DLL.  Correct me 
> if I'm wrong, experts.
>