[DUG] Applicarion.ProcessMessage

[Jolyon Smith]

If the DLL is also a Delphi DLL using VCL controls (as it almost certainly is) then your problem is that the VCL is simply not designed for multi-threading, in so far as all VCL control message processing code assumes that the processing is occurring in the main thread.

This is precisely why Synchronize() was devised, to ensure that if you had to make calls to VCL component code (adding items to list boxes, getting/setting edit control text etc) that this all occurred safely on the VCL message thread and thus would be safely serialised with any message processing that the VCL control(s) involved might be dealing with.

Even if the VCL were thread-safe, if the DLL is creating windows in the context of the VCL thread (which it presumably is) then you also have the problem that a thread cannot process messages for windows created in a different thread.  Each thread that creates windows is responsible for handling the message queue that the system creates for that thread.

Again, due to the nature of the VCL it is difficult - if not impossible - to create an application in Delphi that has multiple UI threads.


You say that things become a problem when the DLL is doing something that takes several seconds.

What is it that triggers the DLL to do this “something” ?

If it is something that occurs “internally” within the DLL, triggered by some user interaction with the UI that the DLL is providing then you are out of luck I think.  But if the long running process in the DLL is triggered by a call made by your application, and if that long running process itself does not involve the DLL’s UI, then you might be able to make that call to the DLL in a background thread.

But you may have trouble even if that is possible, since it is highly unlikely that the DLL is taking care to be thread-safe itself (unless you have the source and can verify otherwise) so the results could be unpredictable.

--  
Jolyon Smith

>  
> On Tuesday, 29 October 2013 at 17:02 , Ross Levis wrote:
>  
> > I’m wondering if any experts out there can help with this issue.
> >   
> > I’m loading a 3rd party DLL which needs to have Windows messages sent to the DLL from my app for navigation purposes.  It has been 10 years since I implemented this code which someone else gave me...
> >   
> > procedure TEngine.ProcessMessage(var Msg: tagMSG; var Handled: Boolean);
> > begin
> >   if not IsChild(Engine.Handle,Msg.hwnd) then
> >   try
> >     Handled := IsDialogMessage(GetParent(msg.hwnd),Msg);
> >   except
> >     Handled := False;
> >   end;
> > end;
> >   
> > Application.OnMessage := ProcessMessage;
> >   
> > Without this the DLL GUI would not show which component had the focus, which was a problem for blind users using the tab key.
> >   
> > The problem:  When the DLL is doing something that takes several seconds, the function above appears to hang waiting for the DLL to finish, and this causes the main thread in my app to also hang.
> >   
> > Is there any way around that, such as using a separate thread to process these messages?  That would be somewhat out of my league.
> >   
> > Cheers,
> > Ross.  
> >   
> >  
> >  
> > _______________________________________________
> > NZ Borland Developers Group - Delphi mailing list
> > Post: delphi at listserver.123.net.nz (mailto:delphi at listserver.123.net.nz)
> > Admin: http://delphi.org.nz/mailman/listinfo/delphi
> > Unsubscribe: send an email to delphi-request at listserver.123.net.nz (mailto:delphi-request at listserver.123.net.nz) with Subject: unsubscribe
> >  
> >  
> >  
>  
>  

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://listserver.123.net.nz/pipermail/delphi/attachments/20131029/221a8c21/attachment.html