>
> I didn't realize that I must admit! Would I be better using
> AllocateHWnd instead, or perhaps creating my own queue object to
> mediate between the two threads?
The problem of 'recreateWindow' changing the handle of a form is not, IME, a
serious problem, at least, it wasn't with earlier versions of Delphi.
Maybee this miserable practice has become more common lately.
I got round this problem with a unit that creates its own 'hidden window'
(using API's), in the main thread, (actually, in the initialization
section). This window, since it is not part of the VCL, is not going to be
recreated or have its handle changed, so messages can be safely posted to
its handle. The WndProc for this hidden window processes only one message
number and this message number can be used for all posts to the main thread.
The handler procedure casts 'wParam' to a TControl and then calls
'TControl.perform' on this TControl with the 'lParam' from the message as
the lParam parameter of the perform call.
This allows any thread to post one 32-bit parameter, (in lParam), to a
TControl, (eg: a form), whose *instance* is in wParam. The Delphi instance
reference does not change, (unless the form is actually destroyed:), and so
this mechanism is safer than direct posting to VCL form handles.
The 32-bit parameter could be anything - 1-4 bytes of direct data, a
dynamically-allocated record or an object. Allocated types must be
disposed/freed/repooled/something after handling in the main thread, to
avoid leaks.
When the app closes, the unit finalization section destroys the hidden
window.
Rgds,
Martin
