Re: [DUG] Application.ProcessMessage

[Jolyon Smith]

Weird.  It could be that the DLL is trying to do it's work on a thread but is using the same thread for it's actual work and for responding to messages or it may be creating separate threads but have synchronization that causes them to block each other.  As I say, without source it's pretty much impossible to say for certain, though keeping an eye on the IDE thread-list window in the debugger might shed some light. Good luck.  :) Ross Levis Wed, 30 Oct 2013 14:33 Except that I can disable the ProcessMessage code and the DLL still functions correctly.  It was added only to resolve the component focus issue.  Without it you couldn’t see which component on the GUI had the focus when tabbing.  So I think it may be the DLL simply occupying the main thread when it starts its work, and I was wrong thinking the messages had something to do with it.   Cheers.   From: delphi-boun...@listserver.123.net.nz [mailto:delphi-boun...@listserver.123.net.nz] On Behalf Of Jolyon Smith Sent: Wednesday, 30 October 2013 8:47 a.m. To: NZ Borland Developers Group - Delphi List Subject: Re: [DUG] Applicarion.ProcessMessage   It is both.  :)   The processing of any message on the message queue consumes the thread pumping that message queue.   The DLL is consuming messages from your message queue but instead of responding to an appropriate message by spawning a separate thread to do the work it requires, it sounds like it is performing that work on the message thread.  The net effect is that your message thread is not “stuck” or “hung” but merely very, very busy, doing the work that the DLL is asking of it.   ProcessMessage isn’t “hanging”.  it’s just doing what it’s been asked to do - processing the message.  :)   It’s no different than if the server request that the DLL is performing were instead part of an OnClick event on a button in your own app.  The app would “freeze” until the server request has complete.  The only difference here is that the “event handler” is somewhere in side that DLL.     This is precisely why event response code should always be as efficient as possible.  Ideally you would do all your application work in a separate thread and leave the main thread to be solely responsible for pumping the message queue.  But even then, if you voluntarily offer up control of your message queue thread to an outside DLL, there is always the risk that they will “abuse" the privilege, as appears to be happening in this case.   --  Jolyon Smith _______________________________________________ NZ Borland Developers Group - Delphi mailing list Post: delphi@listserver.123.net.nz Admin: http://delphi.org.nz/mailman/listinfo/delphi Unsubscribe: send an email to delphi-requ...@listserver.123.net.nz with Subject: unsubscribe Jolyon Smith Wed, 30 Oct 2013 08:46 It is both.  :) The processing of any message on the message queue consumes the thread pumping that message queue. The DLL is consuming messages from your message queue but instead of responding to an appropriate message by spawning a separate thread to do the work it requires, it sounds like it is performing that work on the message thread.  The net effect is that your message thread is not “stuck” or “hung” but merely very, very busy, doing the work that the DLL is asking of it. ProcessMessage isn’t “hanging”.  it’s just doing what it’s been asked to do - processing the message.  :) It’s no different than if the server request that the DLL is performing were instead part of an OnClick event on a button in your own app.  The app would “freeze” until the server request has complete.  The only difference here is that the “event handler” is somewhere in side that DLL. This is precisely why event response code should always be as efficient as possible.  Ideally you would do all your application work in a separate thread and leave the main thread to be solely responsible for pumping the message queue.  But even then, if you voluntarily offer up control of your message queue thread to an outside DLL, there is always the risk that they will “abuse" the privilege, as appears to be happening in this case. --  Jolyon Smith Ross Levis Wed, 30 Oct 2013 03:51 Ok.  I thought it might be the ProcessMessage function that was hanging, but perhaps it is simply the main thread stuck in the DLL and nothing to do with the message processing.   Thanks.   From: delphi-boun...@listserver.123.net.nz [mailto:delphi-boun...@listserver.123.net.nz] On Behalf Of Jolyon Smith Sent: Tuesday, 29 October 2013 8:41 p.m. To: NZ Borland Developers Group - Delphi List Subject: Re: [DUG] Applicarion.ProcessMessage   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:   _______________________________________________ NZ Borland Developers Group - Delphi mailing list Post: delphi@listserver.123.net.nz Admin: http://delphi.org.nz/mailman/listinfo/delphi Unsubscribe: send an email to delphi-requ...@listserver.123.net.nz with Subject: unsubscribe

_______________________________________________
NZ Borland Developers Group - Delphi mailing list
Post: delphi@listserver.123.net.nz
Admin: http://delphi.org.nz/mailman/listinfo/delphi
Unsubscribe: send an email to delphi-requ...@listserver.123.net.nz with 
Subject: unsubscribe