Question

The Application.ProcessMessages command is well known and I use it in long processes to ensure my program will not tie up the computer.

But I have one fairly quick set of processing, where I am buffering a view into a file. During the buffering procedure, a few system messages may get sent off (e.g. redraw or scrollbar move or other events). I want to prevent these from getting handled by ProcessMessages until my buffering is complete.

Is there any way to either:

1. Prevent Application.ProcessMessages until my procedure is complete, or

2. Trap all messages generated during my procedure, and not release them until the end of the procedure.

Answer 1

Allowing the ProcessMessages to continue even if it sends messages you don’t want should not be classed as problematic. With a bit of code refactoring, you could move the buffering method into a separate thread and go from there.

If you are attempting to copy the “visual contents” of a control into a file,

• look at the WM_PRINT(xxx) message which allows child controls to paint themselves into bitmaps
• try the LockWindowUpdate Win32 API method call which will turn off all painting messages to that control
• override the WndProc/DefaultWndProc method on your control class or even the parent class if you need to and simply return “true” for each message sent
• override specific control methods (such as “scroll bar moved”, “OnPaint“, “OnPaintBackground” etc) on the control class or even the parent and simply do nothing if your buffering is in progress

Overriding the WndProc or DefaultWndProc and simply returning true for each message essentially “turns off” ProcessMessages but it’s not safe to do it this way because the control might need to process one or more messages to function correctly.

Turning off ProcessMessages is not possible (without rewriting the VCL code for message processing) because of the fact that it’s part of how the VCL form’s message loop has been constructed.