[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 <mailto:ross at stationplaylist.com>
> 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-bounces at listserver.123.net.nz 
> [mailto:delphi-bounces at 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 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 
> with Subject: unsubscribe
> Jolyon Smith <mailto:jsmith at deltics.co.nz>
> 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 <mailto:ross at stationplaylist.com>
> 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-bounces at listserver.123.net.nz 
> [mailto:delphi-bounces at 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 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 
> with Subject: unsubscribe
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://listserver.123.net.nz/pipermail/delphi/attachments/20131030/da9781da/attachment-0001.html 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: compose-unknown-contact.jpg
Type: image/jpeg
Size: 770 bytes
Desc: not available
Url : http://listserver.123.net.nz/pipermail/delphi/attachments/20131030/da9781da/attachment-0002.jpg 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: postbox-contact.jpg
Type: image/jpeg
Size: 1287 bytes
Desc: not available
Url : http://listserver.123.net.nz/pipermail/delphi/attachments/20131030/da9781da/attachment-0003.jpg