Thank you for your advice.

Am I right in saying that your "asynchronous design pattern" would treat
each "automated process" as an object with inputs and outputs but this
objects code should only be executed as part of the main thread?  I.e. I
think using a TDataModule in this manner is essential the same
philosophy of the design of a state machine.  I assume to use a
TDataModule to do this you would have to keep track of the current
state/step/status/... so the code could respond appropriately to any
events and advance/abort/... the process? 


-----Original Message-----
From: []
On Behalf Of Francois PIETTE
Sent: Wednesday, 16 February 2011 6:24 PM
To: ICS support mailing
Subject: Re: [twsocket] Asychronous opperation of Over Byte
components-Automated processes

> How should one go about coding a user initiated automated/interactive
> processes which use TTnCnx and TTFtpClient?
> The user must be able to cancel the process and respond to prompts as
> required by the process.
> If one uses On... events to trigger the next step the code become part
> of the GUI and is basically a state machine.

A state machine, OK. Part of the UI: you have the choice. In my opinion,


> Do I have any other options with these components?

Sure !
Put your code into a TDataModule, make it do what it needs to and create
events in the datamodule to update the user interface when needed and 
provide methods to be called from the user interface when some user
needs to be done. This is close to two well known design pattern named 
"Inversion Of Control" and "Dependency Injection".

You must think about the user interface layer and the communication
layer as 
two independent processes communicating thru messages (method call), 
properties and events (call back). I like to use the terme "message"
of "method" or "procedure or "function" because in the asynchonous
pattern, a message is a way of sending a request for an operation to be 
executed without actually waiting for the operation to be done. Once the

requested operation is done, an event is triggered to notify the
An event is actually a message from the callee to the caller. Properties
there optionally. Everything propertis carry could be part of messages 
(arguments of methods) or part or events handler arguments. It is often 
easier to use properties to reduce the number of arguments and maybe
come to 
naked message of event: all the information is in properties and message
event is just the notification that something has to be done or is done.

> Can the process be encapsulated in a thread instead where the thread
> can wait for each task to be completed or abort etc. before it moves

This is really bad design. Actually what you would like is to kill the 
asynchronous nature and make it synchonous. Forget about it !
Do the reverse: use a thread when you have a lengthy blocking task (such
large SQL query) so that instead of blocking, it became asynchronous and
well into the whole architecture.

Another usage of thread is to make use of multicore CPU (or multiple
But to benefit from that your application needs to be CPU bound and that
seldom the case unless you are doing scientific application (heavy 
computation). In that case, the long computation is similar to the SQL
I talked above: it is just seen as a lengthy task. The difference is
that a 
computation taks use 100% CPU while a SQL query use almost none (Most
CPU is 
used at the DB server side).

I hope this helps.
The author of the freeware multi-tier middleware MidWare
The author of the freeware Internet Component Suite (ICS)

To unsubscribe or change your settings for TWSocket mailing list
please goto
Visit our website at
To unsubscribe or change your settings for TWSocket mailing list
please goto
Visit our website at

Reply via email to