Application.ProcessMessages is something people like to call often, but what is it, what are the benefits and what are the disadvantages
What is it?
It calls the message pump, which handles incomming Windows messages until there is no more messages in the message queue. Normally it is bad practice to call it directly, unless you are sure you know what you are doing, since Delphi already calls the message pump already while your application is idle.
What are the benefits of calling it?
To be honest... None. If your application is written right, you will never ever have to call it directly. If you really need to call it, you might want to re-evaluate the desing of your application.
But why do people like to call Application.ProcessMessage, if it is so bad?
Well, if your application does not respond when you want it, it is very easy to just call it. It is generally wrong because Delphi does all that for you. People often call it to update the display of some control component, i.e. a Label. But in such cases you are better off calling the Update method of the control itself, which will send (not Post) a message to the window of the control itself and cause the control to be updated immediatly. Almost all control components have an update method, i.e. Label.Update. Also, many people believe they have to pause their application using wait loops while some event happens because they dont understand Windows programming. Then they feel it necessary to insert a call to the message pump in the wait loop or their application will freeze while waiting. This is generally unnecessary and wastes lots of CPU time. In these cases it is best to re-evaluate the design of the application and rewrite it if necessary to take advantage of the event-driven nature of Windows programming.
What are the disvantages?
A lot! For example if you call Application.ProcessMessages from within an event of a component, and if that component generates its events from within the message pump, then you are in deep trouble. In fact, you are calling yourself at that moment. I have made a simple example of what can happen with a simple timer. You can download it at:
http://www.mestdagh.biz/ics/demos/ReEnterTest.zip
As an example, suppose you call the message pump in the OnReceive event of an ICS component. From there you call a Receive method to receive the data. But your code is badly written and slow, so you decide to call Application.ProcessMessages, and if at that time already new data is received by WinSock, your OnReceive handler will be called again before it ends. When the second instance of your OnReceive finishes, the next line of the first instance will continue. You can then imagine what can happen... Corrupted, lost or duplicated data; infinite loop and all sorts of Bad Things.
This is not a component issue, it is the way Windows was design. Before you call the message pump you must learn how the Windows messaging system works, and how messages are transformed to events.
Note that a modal form is calling the message pump also (because it is idle and just waiting for messages, eg a mouse click), meaning that if you display for example a dialog box, then you are indirect calling the message pump, doing the same thing.
