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