Sending messages to non-windowed applications -- AllocateHWnd, DeallocateHWnd

http://delphi.about.com/od/windowsshellapi/l/aa093003a.htm

Page 1: How Delphi dispatches messages in windowed applications

Article submitted by Catalin Ionescu for the Delphi Programming Quickies Contest - Round #2 Winner!

 

Learn how to send signals to non-windowed applications by using AllocateHWND and DefWindowProc.

In this article we also briefly describe what Delphi does in the background to intercept Windows messages,

how can we write our own message handler for a windowed application and

how to obtain a unique message identifier that we can safely use in our applications.

We'll also discover and fix a small bug in the Delphi DeallocateHWND procedure along the route.

 

How Delphi dispatches messages in windowed applications

In the Windows environment a lot of messages flow in the background.

Each time the mouse is moved, a key is pressed, a window is moved or needs to be redrawn and in many other cases

one or more messages is generated and hopefully finds it's way to the appropriate message handler code

that understands and reacts appropriately to that very specific message.

To see some of the messages that are generated automatically by Windows or as a response to your input you can fire up WinSight and peek around.

If we need to receive and react to one of these messages in our application we need to write a message handler.

For example if we need to respond to Windows signaling our main form that it needs to erase the background

(WM_ERASEBKGND message) the typical code that we should place in the interface may be:

procedure WMEraseBkgnd(var Message: TWMEraseBkgnd); message WM_ERASEBKGND;

 

 

Then in the implementation part we would write the actual code that erases the form background.

This is called a message handler.

Delphi needs to do a lot of work in the background to call the above code for each WM_ERASEBKGND message generated by Windows.

First it needs to intercept all Windows messages targeted at our particular form.

Then it needs to sort them out based on the message identifier (WM_ERASEBKGND in the above example)

and find if we implemented a message handler for any of them.

In our above code we signal Delphi that we're only interested in receiving background erase notifications and not,

for instance, mouse clicks.

So Delphi calls our message handler for all background erase notifications and one of its own message handlers

for all other messages received by the form.

Fortunately Windows has a very convenient way of intercepting all messages passed to a form.

Each form has a window procedure that gets called for each and every message the form receives.

As a new form is created the operating system provides a default window procedure

that can be changed later by the application that owns the form if it needs to react on one or more messages.

This is exactly what Delphi does.

As each new form is created Delphi overrides the default window procedure with its own message interceptor and dispatcher.

It is then a simple matter of comparison to find the appropriate message handler,

either internal or written by us, for each specific message identifier.

Non-windowed?

If we write a non-windowed application, for instance a console application or a non-interactive service,

then Delphi doesn't have a default window procedure to intercept and thus we can't rely on him to call our message handler.

We need to write our own window procedure.

But, as our application doesn't have a window, neither do Windows provide us with a window procedure to intercept.

Isn't there a way to trick Windows in thinking we have a window? Find the answer on the next page...

Page 2: How to send messages to non-windowed applications

Now that you know how Delphi dispatches messages in windowed applications,

it's time to trick Windows in thinking we have a window in a non-windowed application

How to send messages to non-windowed applications

Isn't there a way to trick Windows in thinking we have a window?

We could create one but having tens of windows displayed all across the screen

just for the purpose of intercepting Windows messages is inaesthetical and unpractical.

What if we could create a window but mark it in such way so it is not displayed on the screen?

We could reach our goal of having a window procedure and

at the same time don't fill the screen with dummy empty windows.

Again Delphi VCL addresses this very specific need by providing a convenient wrapper that handles all the low-level API calls.

It provides two functions that must be used in pairs:

AllocateHWND and DeallocateHWND.

First one accepts a single parameter that is our window procedure

and the second one does the cleanup when we no longer need the invisible window.

We have created a sample application that shows the usage of AllocateHWND/DeallocateHWND functions.

To simulate a non-windowed application we will use a TThread descendent, defined as follows:

TTestThread = class(TThread)
private
  FSignalShutdown: boolean;
  { hidden window handle }
  FWinHandle: HWND;                       
protected
  procedure Execute; override;
  { our window procedure }
  procedure WndProc(var msg: TMessage);   
public
  constructor Create;
  destructor Destroy; override;
  procedure PrintMsg;
end;

 

Creating the hidden window

In the TTestThread constructor we create our hidden window which is destroyed in the TTestThread destructor:

constructor TTestThread.Create;
begin
  FSignalShutdown := False;
  { create the hidden window, store it's handle and change the default window procedure provided by Windows with our window procedure }
  FWinHandle := AllocateHWND(WndProc);
  inherited Create(False);
end;

destructor TTestThread.Destroy;
begin
  { destroy the hidden window and free up memory }
  DeallocateHWnd(FWinHandle);
  inherited;
end;

 

To test for the message routing we use a simple boolean (FSignalShutdown)

that we initially set to False in the constructor and

will hopefully be set to True in the window procedure (WndProc) upon receiving our message.

The window procedure

In order to keep things simple we have implemented a bare-bone window procedure as follows:

procedure TTestThread.WndProc(var msg: TMessage);
begin
  if Msg.Msg = WM_SHUTDOWN_THREADS then
    { if the message id is WM_SHUTDOWN_THREADS do our own processing }
    FSignalShutdown := True 
    else
    { for all other messages call the default window procedure }
    Msg.Result := DefWindowProc(FWinHandle, Msg.Msg, Msg.wParam, Msg.lParam);
end;

 

This procedure is called for each and every Windows message,

so we need to filter out only those that are interesting,

in this case WM_SHUTDOWN_THREADS.

For all other messages that are not handled by our application remember to call the default Windows procedure.

Even if this is not so important for our non-visible non-interactive window

it is a good practice and missing this step may yield to unpredictable behaviors.

Message identifier?

If applications were to use arbitrary message id's their operation would soon interfere

and messages meant for one application would be interpreted in unknown and unwanted ways by others. 

To prevent this Windows provides a way for each application or related applications to obtain a unique message identifier.

How? Find on the next page...

Page 3: Obtaining a unique message identifier. The DeallocateHWND bug.

Until now, we've covered how Delphi dispatches messages in windowed applications,

and how to send messages to non-windowed applications,

we move on to obtaining a unique message identifier.

Obtaining a unique message identifier

As stated on the previous page, if applications were to use arbitrary message id's their operation would soon interfere

and messages meant for one application would be interpreted in unknown and unwanted ways by others.

To prevent this Windows provides a way for each application or related applications to obtain a unique message identifier.

var
  WM_SHUTDOWN_THREADS: Cardinal;

procedure TfrmSgnThreads.FormCreate(Sender: TObject);
begin
  WM_SHUTDOWN_THREADS := RegisterWindowMessage('TVS_Threads');
end;

 

We pass a unique string identifier to the RegisterWindowMessage and it returns a message identifier that is guaranteed to be unique across a Windows session.

The application

All that remains is to put all the above code together. You can download the full source code.

To test the application we create a few threads by pressing the New Thread button,

then notice how all of them correctly receive the WM_SHUTDOWN_THREADS message

when we press the Send Signal button.

To view the internal flow of code we printed a message when each thread is created and another message

when the thread receives the message and is destroyed.

Everything works as expected.

But as the threads and the hidden windows are destroyed

we will soon notice a lot of exceptions popping up.

DeallocateHWND bug

We tried to narrow down the source of the problem.

From the exception message we concluded there's probably a reference to unallocated memory at some point.

The only places where we deallocate memory are when the threads themselves are destroyed

and when the hidden window is destroyed.

First we moved the DeallocateHWND call to the Execute procedure and comment the FreeOnTerminate line,

so the threads don't destroy automatically:

procedure TTestThread.Execute;
begin
  { FreeOnTerminate := True; }
  while NOT FSignalShutdown do
  begin
    Sleep(10);
  end;
  Synchronize(PrintMsg);
  { destroy the hidden window and free up memory }
  DeallocateHWnd(FWinHandle);
end;

The errors still show up.

So it must be something related to the DeallocateHWND call

so we look at the Delphi DeallocateHWnd implementation which is in the Classes unit:

procedure DeallocateHWnd(Wnd: HWND);
var
  Instance: Pointer;
begin
  Instance := Pointer(GetWindowLong(Wnd, GWL_WNDPROC));
  DestroyWindow(Wnd);
  if Instance <> @DefWindowProc then FreeObjectInstance(Instance);
end;

At first glance everything looks fine.

The window is destroyed and the memory occupied by our window procedure is freed.

But... after we free up the memory occupied by our window procedure a few messages

are still routed to the hidden window

(yes, there are still messages routed to that window, including a bunch of WM_DESTROY and its relatives).

So Windows will try to reference an unallocated memory space

when trying to execute our window procedure and thus an exception will pop up.

The solution we have found is to slightly alter the DeallocateHWnd code to change back the window procedure

to the default one provided by Windows before we free up the memory for the code.

procedure TTestThread.DeallocateHWnd(Wnd: HWND);
var
  Instance: Pointer;
begin
  Instance := Pointer(GetWindowLong(Wnd, GWL_WNDPROC));
  if Instance <> @DefWindowProc then
  begin
    { make sure we restore the default 
      windows procedure before freeing memory } 
    SetWindowLong(Wnd, GWL_WNDPROC, Longint(@DefWindowProc));
    FreeObjectInstance(Instance);
  end;
  DestroyWindow(Wnd);
end;

You can download the full source code of the application with the fix here.

We notice that all errors are gone and conclude the error was indeed in the DeallocateHWnd code.

If you have any questions or comments I would like to receive them in the Delphi Programming Forum 

and I'll try to answer all to the best of my knowledge and abilities.