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, not.

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 new events in the datamodule to update the user interface when needed and provide methods to be called from the user interface when some user action 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" instead of "method" or "procedure or "function" because in the asynchonous design 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 requestor. An event is actually a message from the callee to the caller. Properties are 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 or 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 on?

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 a large SQL query) so that instead of blocking, it became asynchronous and fit well into the whole architecture.

Another usage of thread is to make use of multicore CPU (or multiple CPU). But to benefit from that your application needs to be CPU bound and that is seldom the case unless you are doing scientific application (heavy computation). In that case, the long computation is similar to the SQL query 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

Reply via email to