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.
--
francois.pie...@overbyte.be
The author of the freeware multi-tier middleware MidWare
The author of the freeware Internet Component Suite (ICS)
http://www.overbyte.be
--
To unsubscribe or change your settings for TWSocket mailing list
please goto http://lists.elists.org/cgi-bin/mailman/listinfo/twsocket
Visit our website at http://www.overbyte.be
