I have a program flow problem that I hope some more experienced OOP
programmers can help me with.

I'm writing a scientific algorithm in Delphi.  The program collects various
sorts of information from the user, and then proceeds to run an iterative
algorithm, plotting intermediate results on the screen and allowing the
user to stop it at any time.

The program presents several forms to the user to collect input.  The first
form is always the same, but depending on the selections made there, the
program can branch.  The input must be collected in the order that the
forms appear.

Currently, the program logic (branching control etc) is embedded in the
OKButtonClick event handlers for each form.  I find this particularly
inelegant, and I wanted to create some kind of abstract control object that
has an appropriate method like ControlObject.CollectInputs.  This would
allow me to keep the program flow control logic all in one place where it's
easy to read and modify.

My problem is this: I can't figure out a way to instantiate the
ControlObject and run the CollectInputs method.  I could put it into the
OnCreate method of the MainForm, but that also seems inelegant: then the
whole program runs "inside" the MainForm.OnCreate method.  Likewise, after
the algorithm finishes, the user should be able to start it again for a
different set of inputs.  Thus, the MainForm has a menu bar, one item of
which is something like "Run".  But again, when I click this menu item, the
whole program then runs "inside" the MainMenu.ItemRunClick event handler.

Is there some standard way to control program flow like this?  Or is there
really no problem (except my spiritual longing for elegance) in running
everything inside MainForm.OnCreate and MainMenu.ItemRunClick?  Being a
scientist rather than a real programmer, I sure could use some advice from
you more experienced guys!

--
Ken DeLong          
Check out the FROG Web page at http://www.ca.sandia.gov/ultrafrog
Personal Page http://ourworld.compuserve.com/homepages/ken_delong

On Mon, 25 Nov 1996 09:57:19 -0800, delo...@llnl.gov (Kenneth W.

The most common way to understand event-driven programs is to model
the program as a finite state machine. The events control the
transitions. The various states correspond to different forms,
enabling or disabling controls, and so on.

Instead of thinking about "running" a program, try to think about
states and transitions. You can centralize the state control logic,
but let each form manage its own state transitions, perhaps checking
with the central control logic to verify legal transitions and to know
which form (state) to invoke next.

--
Ray Lischner, Tempest Software, Inc., Corvallis, Oregon, USA
Author of Secrets of Delphi 2 (http://www.tempest-sw.com/secrets/)

It's late, but let me propose an architecture for this:

Define control objects that are distinct from the TForm (GUI) and that
each represent one of the distinct parts of the data that can be
collected. You may already have these, but if not, you can use
TDataModules or just plain old Pascal Units.

Define a procedure for each one of these objects to enable it to
present itself on screen (via the appropriate TForm) for data entry.

Define a function for each one of these objects that knows whether or
not it should present itself and which objects it should call next if
it does. Each such function returns true if it does, false if it does
not. You may need to know what state you are in to make that decision
and you may need to change that state depending on the kind of data
you collect and so forth. You do not change state on false returns.

These objects become the self-controlled mechanisms for your system,
and drive the system from a middle tier rather than the GUI forms. I
think this is a good way for a classical language like OP. For a
classless language like Smalltalk, I would prefer class methods.

When only one instance of each form is ever needed and if the forms
can all be created at system start up (the Delphi default for Single
Document Interface), then you can combine the control object together
with the form it would have presented into a single module. The
procedure to present itself can just set "Visible := true;" because
the form is already created by Delphi. If the form were not created,
it would not make sense to ask if it should present itself.

Leo

On Mon, 25 Nov 1996 09:57:19 -0800, delo...@llnl.gov (Kenneth W.