separate gui & program flow

Be more specific.
If you take a look at some database examples they use datamodules to
encapsulate database access and rules, and there are forms which use them
(their dataset objects or data objects and methods).
Second step is to abstractize data access: your forms and code do not access
dataset objects and their records directly but via intermediate objects.
This pays off if data access layes or format or rules change.
Most common today is middle tier - an application server that encapsulates
database access and business rules. So, a GUI can be almost anything -
Delphi application, C++ application, VB application, browser, .net
application,... (the last not recommended for at least a year).
Also, the client application can be on same machine as app server or any
remote machine that can connect to it.
You already have all of above in Delphi.

--
Robert
---------
"There are only 10 kinds of people in the world --
   Those who understand binary, and those who don't."

Quote
"Benson" <ben...@edihk.com.hk> wrote in message

news:3de6cb5b$1@newsgroups.borland.com...
Quote
> Can any components are designed to help to seperate GUI and program logic
> coding?

> E.g. Customer Master Maintenance program
> A) cust_gui.pas, cust_gui.dfm (may be in other formats other than pas/dfm)
> ------------------------------------------------------
> | customer no.: ________________             |
> | name: _______________                          |
> | address: ___________                              |
> |-----------------------------------------------------|
> no more coding.

> B) cust_code.pas, cust_code.dfm
> ...
> select * from custTable
> ....
> // checking
> ...
> // posting
> .....
> =============================================
> if there is any modification in gui, just update cust_gui.* and copied to
> the clients.

> Any idea?

> Delphi 5.0, Interbase 6.02
> Benson