Aplpication.ProcessMessages within a Thread

>. Application is still VCL and as such, should never be referenced within a thread.
outside the synchronize call ;) and you can reference it, it's the methods that usually cause problems (executing code). reading properties is ok (in case of TApplication). writing them is probably problematic in some cases.
basically, you just need to pay attention to what you're doing and with what.
just because everything seems to work fine it doesn't mean that the bug is not there. since the call is somewhere deep, you might not get to execute that but in rare cases.

I just made a quick research into this and in case of application.processmessages it's like this:

http://msdn2.microsoft.com/en-us/library/ms644943(VS.85).aspx
"If hWnd is NULL, PeekMessage retrieves messages for any window that belongs to the current thread, and any messages on the current thread's message queue whose hwnd value is NULL (see the MSG structure). Therefore if hWnd is NULL, both window messages and thread messages are processed."

so, calling application.processmessages which in turn will call peekmessage will process the messages belonging to the current thread, which is either the mainvcl thread or the thread from which it is called.

basically, it does nothing, unless the thread owns some windows (which I doubt) or has some messages in it's queue (which again, I doubt) (I am assuming that it's all TThread, which doesn't have neither of them)

you should also check if the application.processmesseges is not called in an event handler. because if it is and the event is fired in the vcl thread context, thenit makes sense. so don't go running commentign it out, first try to understand why it is there ;)

Ciuly - thanks

The problem I've found is that the ICS WSocket DOES create a hidden window and inserts into the WNClass structure of this window its own message processing function. THis is causing problems freeing the threads (and is related to another open question I have) - when a thread is freed (and therefore the socket) alt-tabbing or changing focus to another application causes my application to immediately crash. I think it's redirecting message to an invalid window...., something I've yet to solve.

I don't know about ICS. I dropped that quite a few years back in favor of indy :)

you could do the same, too :D

I've used both ICS and Indy a lot. I personally prefer ICS because it's async.
Never had any problems with ICS in a thread though.

MerlinB

If you could explain why, when I free an ICS socket component within a thread, my application crashes when focus is removed from it, you'll be, well, you'll be - I'll tell you what you'll be - you'll be the godfather to my brothers children when he decides to have some.

http://www.experts-exchange.com/Programming/Languages/Pascal/Delphi/Q_23220172.html

It's definitely the socket causing this, and the socket's creation (for some reason) of the hidden window. I really don't know how to solve it.

Regards


Steve