[DUG] Applicarion.ProcessMessage
Jolyon Smith
jsmith at deltics.co.nz
Tue Oct 29 20:41:12 NZDT 2013
If I have understood correctly and the DLL polling is occurring on the main thread then you don’t have the option of changing ProcessMessage once the message that triggers the DLL processing has been dispatched. As soon as that message is processed, causing the DLL to go off and do it’s thing, your VCL thread is already committed to servicing that DLL.
--
Jolyon Smith
On Tuesday, 29 October 2013 at 19:54 , Ross Levis wrote:
> It’s actually a C++ DLL, not VCL based.
>
> The DLL is polling for a window title to change in my app, and executes when it detects a change.
>
> What I thought of doing was set OnMessage to nil when I update the window title, and set it back to ProcessMessage on a timer shortly afterwards. I’m not sure if that will work or not and it will be impossible to test. The DLL is in fact updating a server via the internet, and only if there is an issue updating the server does the delay occur, and I can’t emulate that situation unfortunately. Could be worth a try and send it out to users.
>
> Ross.
>
> From: delphi-bounces at listserver.123.net.nz [mailto:delphi-bounces at listserver.123.net.nz] On Behalf Of Jolyon Smith
> Sent: Tuesday, 29 October 2013 7:36 p.m.
> To: NZ Borland Developers Group - Delphi List
> Subject: Re: [DUG] Applicarion.ProcessMessage
>
> 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
> > >
> > >
> > >
> > >
> >
> >
> >
> >
> >
>
>
>
>
>
> _______________________________________________
> 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/85c590d7/attachment.html
More information about the Delphi
mailing list