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] Admin: http://delphi.org.nz/mailman/listinfo/delphi Unsubscribe: send an email to [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
