TURBU Tech

When you work with UIs, order of operations can be very important.  Windows’s UI works based on an event queue and a message pump that reads events from the queue and dispatches them.  And since the UI is single-threaded, this means that at any time, there could be pending events about to execute while you’re handling some UI code.

Sometimes you’ll get into a situation where you need to execute something, but not right away; you need it to happen after all of the pending events have processed.  Now, obviously, the best way to make something happen after everything in the queue has processed is to put something else onto the queue directly behind everything that’s currently in there.  But the tricky part is what happens when it comes back out.

Messages get posted to a HWND (window handle) and get dispatched to the associated window’s WndProc routine, where they’re handled based on their message type, which is a 2-byte integer value.  There are a bunch of reserved constant values with specific meanings to Windows. WM_PAINT, for example, tells a visual control to repaint itself.  But there’s also a reserved value called WM_USER.  Everything from this constant onward can be used as a user-defined message.

Delphi makes associating a message constant with a method of an object very easy; all you need to do is put a message directive after the declaration, with a value indicating the message type it should respond to.  But because messages get dispatched to a HWND, this will only work for a pretty narrow subset of objects.

Interestingly enough, there is a way built in to Delphi to post a message to the queue of the main (UI) thread, which will execute an arbitrary procedure when the message is read.  It’s the TThread.Queue routine.  Unfortunately, as the name implies, it only works correctly when used from another thread.  The documentation warns you not to call TThread.Queue from the main thread.  Looking through the code, I’m not completely sure what will happen if you do, but it looks like it will just execute your routine immediately instead of posting it to the event queue for delayed execution.

So the obvious solution if you want to queue something up from the main thread is a bit ugly: spawn a thread that calls TThread.Queue and then terminates.  But now you’re introducing all sorts of new things that can go wrong!

Well, I’d run into a need to do this a handful of times, and I’d always had a form or other control available that I could attach a message handler to… until last week.  I was inside an object that is not a visual control, but which creates a form, calls ShowModal on it, and then releases the form when it’s done.  Problem is, both that modal form and the base form that the current code was working with (but was not part of) displayed OpenGL contexts, and due to various factors the GL drawing state was getting corrupted.  So I needed some way to reset things, but I had to wait until the modal form was finished cleaning up.  The Release method works based on delayed action, to let a form finish any queued processing before destroying it, but that means that my reset code had to also execute delayed.

After thinking about it for a while, here’s what I came up with.  In 90 lines of code, it duplicates the functionality of TThread.Queue–taking an anonymous procedure with no arguments and queuing it up for delayed execution on the main thread–except that it works correctly when called from the main thread.

[code lang="Delphi"]
{*****************************************************************************
* The contents of this file are used with permission, subject to
* the Mozilla Public License Version 1.1 (the "License"); you may
* not use this file except in compliance with the License. You may
* obtain a copy of the License at
* http://www.mozilla.org/MPL/MPL-1.1.html
*
* Software distributed under the License is distributed on an
* "AS IS" basis, WITHOUT WARRANTY OF ANY KIND, either express or
* implied. See the License for the specific language governing
* rights and limitations under the License.
*
*****************************************************************************
*
* This file was created by Mason Wheeler.  He can be reached for support at
* www.turbu-rpg.com.
*****************************************************************************}

unit delayedAction;

interface
uses
  SysUtils;

procedure DelayExec(const action: TProc);

implementation
uses
   Windows, Messages, Generics.Collections, Classes, Forms;

type
   TDelayQueue = class
   private
      FQueue: TThreadedQueue;
      FHandle: HWND;
      procedure MainWndProc(var Msg: TMessage);
      procedure Dequeue;
   public
     constructor Create;
     destructor Destroy; override;
   end;

{ TDelayQueue }

constructor TDelayQueue.Create;
begin
   FHandle := AllocateHWnd(self.MainWndProc);
   FQueue := TThreadedQueue.Create;
end;

destructor TDelayQueue.Destroy;
begin
   FQueue.Free;
   DeallocateHWnd(FHandle);
   inherited Destroy;
end;

procedure TDelayQueue.Dequeue;
var
   proc: TProc;
begin
   proc := FQueue.PopItem();
   proc();
end;

procedure TDelayQueue.MainWndProc(var Msg: TMessage);
begin
   try
      if Msg.Msg = WM_USER then
         dequeue
      else DefWindowProc(FHandle, msg.Msg, msg.WParam, msg.LParam);
   except
      Application.HandleException(Self);
   end;
end;

var
   delay: TDelayQueue;

procedure DelayExec(const action: TProc);
begin
   delay.FQueue.PushItem(action);
   PostMessage(delay.FHandle, WM_USER, 0, 0);
end;

initialization
   delay := TDelayQueue.Create;
finalization
   delay.Free;
end.
[/code]

I figured I may as well share it. Feel free to use this if you’re ever in a situation where you need delayed execution.