Can you receive Events in a secondary thread in Delphi XE?

I would like to have three threads in a sample application.

Thread #1 (Main Thread) - User Interface/GUI

Thread #2 - Tied to a serial port device receiving data via events passing to a data queue.

Thread #3 - Activated when a queue entry is made, process data node, frees data object.

The goal is to

a) Prevent the loss of data when a button or the form is held by the mouse on the main form.

b) Quickly get the data from the event, stuff it in the queue, go back to sleep

c) Process data when we have it, otherwise sleep.

Can packages like AsyncoPro tie event handling to a non-main thread?

I've never done much with serial port event driven apps, most of what I've work with are polled and I want to do some testing.

You can definitely tie event handling to a non-main thread. What you can't do is tie screen updating to a non-main thread. The Windows API is not threadsafe, and so the Delphi VCL, which is built on top of the Windows API, isn't either. But your design is basically a good, workable idea; just remember to use the Synchronize or Queue methods of TThread to send any UI updates back to be executed on the main thread.

The easiest should be to define some user messages, then sent it from sub-threads to the main thread.

It's perfectly thread-safe, and even process-safe.

Use PostMessage() with the Handle of the main form. But don't broadcast this WM_USER+n message to the whole UI, because you could confuse some part of the VCL which defines its own custom messages.

If you want to copy some textual data accross threads or processes, you can see WM_COPY_DATA. In practice, this is very fast, faster than named pipes for small messages.

For User Interface, I discovered than a stateless implementation is sometimes a good idea. That is, you don't call-back the main thread via a Synchronize() call or a GDI message, but your main GUI thread has a timer which check a shared memory buffer for pending updates. This is how the web works, and in practice, it's pretty easy to work with: you don't have to write any callback, each thread is independent, do its own stuff, and refresh when necessary.

But of course, the solution depends on your exact project architecture.

For a simple but proven library, see AsyncCalls, working from Delphi 5 up to XE. For latest versions of the IDE (Delphi 2007 and later), take a look at OmniThreadLibrary. By using such libraries, you'll ensure that your software implementation won't break anywhere: it's very common for a multi-threaded application to work as expected most of the time, then, for unknown reasons, going into an endless loop. And, of course, it happens only on the customer side, not yours... If you don't want to spend hours debugging your program, just trust those proven libraries, which are known to be well designed and debugged.

Sure you can do this, one way or another. Not used Apro since D5 - the Apro I have does not work on my D2009, (unicode/string/ANSIstring issues), & I have my own serial classes. Most of the available serial components have the option of firing dataRx events on either the rx thread or the main GUI thread - obviously in your case you should select the rx thread, (Thread #2). Shove the rx data into some buffer class and push it onto a producer-consumer thread to (Thread #3). Process it there. If you need to do a GUI update from there, PostMessage the reference to the GUI thread and handle it in a user-defined message-handler procedure.

Done this sort of stuff loadsa times - it will work OK.

Rgds, Martin