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: [email protected] > [mailto:[email protected]] 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: [email protected] (mailto:[email protected]) > > > > > > Admin: http://delphi.org.nz/mailman/listinfo/delphi > > > > > > Unsubscribe: send an email to [email protected] > > > (mailto:[email protected]) with Subject: unsubscribe > > > > > > > > > > > > > > > > > > > > > > > > > > > > _______________________________________________ > NZ Borland Developers Group - Delphi mailing list > Post: [email protected] (mailto:[email protected]) > Admin: http://delphi.org.nz/mailman/listinfo/delphi > Unsubscribe: send an email to [email protected] > (mailto:[email protected]) with Subject: unsubscribe > >
_______________________________________________ NZ Borland Developers Group - Delphi mailing list Post: [email protected] Admin: http://delphi.org.nz/mailman/listinfo/delphi Unsubscribe: send an email to [email protected] with Subject: unsubscribe
