Calling Application.ProcessMessages in a Delphi program
Using Application.ProcessMessages is being frowned upon by many because often it means that your program design is flawed. These people usually suggest you should use multi-threading instead, which then opens another can of worms.
First of all, let me make clear, that I am talking about Windows programs written in Delphi using the Visual Component Library (VCL). This is not about Android or IOS development and also not about the Firemonkey (FMX) framework and most certainly not about any dotNET language.
With that out of the way, let’s discuss what Application.ProcessMessages does and why it is being used:
Application is the global object declared by the VCL in the Forms unit which provides methods that are independent of forms. One of them is ProcessMessages. What it does is looking into the Windows message queue and processing any messages it may find there. Since Windows GUIs are message driven, this is important for a program to react to user input as well as other events, e.g. redrawing controls that have changed.
Normally this processing of messages is done automatically in the program’s main message loop that is executed all the time when it is idle. But if your program does some long running work after e.g. the user pressed a button, it might take a while until it gets back to executing the message loop and to the user it will seem to have crashed or hung.
To alleviate this, for many years Delphi programmers have added the occasional call to Application.ProcessMessages in their code. This usually looks like this:
proccedure TMyForm.b_Exectue(Sender: TObject);
var
i: integer;
begin
for i := 0 to GetCount - 1 do begin
DoSomeWork(i);
Application.ProcessMessages;
end;
end;
Where DoSomeWork does part of the total work and returns. And then the program calls Application.ProcessMessages to update the user interface.
Why is this bad?
Processing Windows messages may have some undesired side effects. E.g.:
Your form might have multiple buttons which do different things. ButtonA might start a long running calculation A while ButtonB might start a different calculation B. And it’s most likely that you don’t want to start calculation B while calculation A is still running.
Your calculation might access the user interface to retrieve some configuration. If you do that frequently and in between call Application.ProcessMessages, these settings may have changed, so you might start with one set of configurations and continue with a different one. The result will most likely not be what you expect.
The user might close the form while the calculation is still running. That could result in resources that the calculation needs being freed, which usually causes errors like Access Violations.
Each call to Application.ProcessMessages takes time which might slow down your calculations significantly.
So, should we not call Application.ProcessMessages? And how do we keep the GUI active?
As mentioned above, the answer you usually get is to use multi-threading. That is: Move the work into a secondary (or even many secondary) worker thread and let the main thread take care of the user interface. If done properly this works very well. But can you do it properly? Well, I for one have written my share of multi-threaded programs and I can tell you: It’s difficult to do it properly. And most of the time it isn’t necessary.
One of the main stumble blocks is debugging. The Delphi debugger is not particularly suited for debugging multi-threaded programs. It shows you a list of threads and the code which is being executed by the currently active thread (on a multi core system, there is more than one currently active thread, I have no idea how the debugger selects the one to display). You can switch to a different thread and look at the code it is executing. Even worse: The debugger will switch between the threads automatically for no apparent reason, so you press F8 to step over one command and find yourself in the code of a different thread all of a sudden. Other than the debugger, there are of course other debugging methods, e.g. writing to a log or showing message boxes. The latter can only be done safely in the main thread because the VCL is not thread safe. Writing a log will pose the challenge of accessing that log in a thread safe manner.
All that does not mean, you should not use multi-threading if you need it. It just means that you should consider the implications this will have on the complexity of your code and debugging it.
This blog post is not about multi-threading in particular but about Application.ProcessMessages, so I will not go down that route any further.
So, what can we do with a single threaded program to alleviate the above mentioned pitfalls of Application.ProcessMessages?
First of all: Once you start processing some data, stop the user from interfering.
Disable the controls in the user interface, including the button that just started the processing. This also gives the user feedback that the program is busy right now. He cannot start anything else and also not change the settings being used by the calculations. Don’t forget to enabled the controls afterwards (e.g. use Try…Finally to ensure them to be re-enabled.)
Prevent the current form from being closed. This can be done with an OnCloseQuery event.
Call Application.ProcessMessages as often as necessary, but not too often.
In addition you should provide a visual feedback of the progress and have an Abort button that allows the user to – well – abort the calculations.
Basically you do something like this:
procedure TMyForm.SetIsRunning(_Value: boolean);
begin
// set a flag that can be checked elsewhere
FIsRunning := _Value;
// en-/disable the button that started this
b_Execute.Enabled := not _Value;
// en-/disable any configuration controls
fe_InputFile.Enabled := not _Value;
fe_OutputFile.Enabled := not _Value;
chk_SomeSetting.Enabled := not _Value;
// en-/disable the Abort button, note the missing "not" here!
b_Abort.Enabled := _Value;
// ensure that the Abort button has the correct caption
b_Abort.Caption := _('Abort ...');
// reset a flag that tells you to abort
FAborting := False;
end;
procedure TMyForm.FormCloseQuery(Sender: TObject; var CanClose: Boolean);
begin
Result := not FIsRunning;
// you might want to add a message box here to ask the user if he
// wants to abort
end;
procedure TMyForm.b_AbortClick(Sender: TObject);
begin
// you might want to add a message box here to ask the user if he
// really wants to abort
// set the flag that the user wants to abort processing
FAborting := True;
// give him feedback that we are doing what he requested
b_Abort.Caption := _('Aborting ...');
end;
procedure TMyForm.b_ExecuteClick(Sender: TObject);
var
LastAPMCall: Int64;
ThisAPMCall: Int64;
i: integer;
begin
SetIsRunning(True);
try
LastAPMCall := GetTickCount;
for i := 0 to GetCount - 1 do begin
DoSomeWork(i);
// now, instead of calling Application.ProcessMessages every time
// we check that the last call was more than 100 ms ago
ThisAPMCall := GetTickCount;
if (ThisAPMCall - LastAPMCall > 100) or (ThisAPMCall < LastAPMCall) then begin
// GetTickCount is a 32 bit value that wraps around about
// every two weeks. That's what the second check is for.
Application.ProcessMessages;
LastAPMCall := ThisAPMCall;
if FAborting then begin
// The user has pressed the Abort button, so we do what he wants
SysUtils.Abort;
end;
end;
end;
finally
SetIsRunning(False);
end;
end;
That’s the basic principle which many of our internal tools use. It avoids the complexity of multi-threading while still keeping the UI responsive and allow the user to abort processing. I’m not claiming that it is perfect but it works, is simple to understand and also simple to debug.
Drawbacks are the following:
If the processing is more complex and should be moved to a procedure in a different unit, it’s easy to forget the Application.ProcessMessages calls. Also if you have these calls in your code, you should not call it in a secondary thread. Bad things will happen, if you do.
If you call Application.ProcessMessaging in multiple places, it might not be as easy as in the example to keep track of how long ago the last call was. One possible solution is to have a global TTimedProcessMessages object that does the time keeping for you.
Checking the Abort button is also a problem once your code is no longer in the form’s object. Again, a TTimedProcessMessages object can solve that.
You cannot use that code in Firemonkey programs and, most unfortunately, you cannot use it for cross platform programs (which would require Firemonkey anyway.)
Nowadys most computers have multiple cores. This is a single threaded program, so it will only use the processing power of one core. Depending on the amount of processing that needs to be done and whether it can be split into independent work packages, a multi-threading solution would be much more efficient.
Oh, you might ask, where this TTimedProcessMessages object I am talking about can be found. Here you go:
type
PBoolean = ^Boolean;
TTimedProcessMessages = class
private
FDummyBool: Boolean;
FAbortedFlag: PBoolean;
FLastCall: Int64;
FMinTicks: Int64;
public
constructor Create(_MinTicks: integer; _AbortedFlag: PBoolean = nil);
function Execute(var _WasAborted: boolean): boolean; overload;
function Execute: boolean; overload;
end;
constructor TTimedProcessMessages.Create(_MinTicks: integer; _AbortedFlag: PBoolean = nil);
begin
inherited Create;
FMinTicks := _MinTicks;
if Assigned(_AbortedFlag) then
FAbortedFlag := _AbortedFlag
else
FAbortedFlag := @FDummyBool;
end;
function TTimedProcessMessages.Execute(var _WasAborted: boolean): boolean;
var
ThisCall: Int64;
begin
ThisCall := GetTickCount;
Result := (ThisCall - FLastCall > FMinTicks) or (ThisCall < FLastCall);
if Result then begin
Application.ProcessMessages;
_WasAborted := FAbortedFlag;
end else
_WasAborted := False;
end;
function TTimedProcessMessages.Execute: boolean;
var
DummyBool: Boolean;
begin
Result := Execute(DummyBool);
end;
You either create a global variable (no, of course that’s bad) a singleton of this class
gblTimedProcessMessages := TTimedProcessMessages.Create(100, @FAborting);
or create an instance and pass it around to all methods that need it. These methods then use it like this:
if gblTimedProcessMessages.Execute(WasAborted) and WasAborted then
SysUtils.Abort;
(Note: All the code above has just been typed in as I went along, so it might contain bugs. I haven’t even tried to compile it.)
There you go. Good thing I have disabled comments on this blog anyway, so there will be no way for people to call me unprofessional because I recommend using Application.ProcessMessages. 😉
But if you really want to call me names, here is the corresponding Google+ post.
Read More
