[dba-VB] Run state class

Awhile back I wrote about a RunState class we were developing to control starting and stopping long 
running processes and I thought I would provide an update.

In our program we have processes which we start running and they stay running until we specifically 
stop them.  These processes often start other processes etc.  These processes need an interface for 
the parent to use to tell them to start and stop and then to be able to monitor the process to see 
what state it is in.

We have developed a class which we use to control the "run state" (as we call it) of a process.  Any 
class which is going to communicate a Start / Stop and a running  / stopping / stopped kind of 
status uses this class.

The class encapsulates a check box.  There may or may not be a checkbox of course, often only the 
parent process is told to start / stop via a check box, but that parent process may have N sub 
processes that it can start and stop.  The sub processes do not have a check box.

So, we have a form with three processes which we can start running by checking a check box and which 
we can then then stop by unchecking the check box.

When the check box is checked, an event fires.  The RunState class sinks the events of the check box 
and sets its label to "Running".  The Runstate class then does one of two things.  The RunState 
class has an optional parameter in the constructor which tells it whether the Runstate parent is 
threaded or not.  The run state class has a thread object which it can initialize.  So if the 
RunState parent is threaded, the checkbox event sink creates the thread and the thread raises a 
Start event.  If the Runstate parent is not threaded, then the checkbox event sink simply directly 
raises the same Start event.

In either case the Runstate Start event is sunk in the parent class and the parent class does 
whatever it is designed to do.  When the parent class finishes whatever it does, it calls the 
mStopped method of the RunState class telling the Runstate class that it is finished processing. 
This method sets the Runstate property to Stopped, updates the checkbox label (if any) to Stopped, 
and disconnects the thread object.

If the check box is unchecked, the event is sunk and the runstate class sets the label to 
"Stopping".  The runstate class raises an event telling the parent class to stop.  When the parent 
of the RunState class cleans up and determines it is done with it's process, it calls 
RunState.MStopped just as in the discussion above.

The objective of all this stuff is to provide an encapsulated and consistent way for processes to 
communicate with each other. I (the user) needed a way to start and stop processes via a user 
interface, and shut down those processes in a clean consistent manner.  I have a form which provides 
the parent process a check box and a status list object.  The process can be time consuming, it may 
be creating a table of a million records to output to disk and creating the file on disk.  If I 
start this process, it cannot be terminated until the process reaches some defined point, IOW it 
cannot just be shut down in the middle of filling the table or writing the file to disk.

Bu providing a process with an instance of this RunState class, a parent process can start a child 
process and monitor the progress.  If needed the RunState class can provide a thread to the process 
and can also manage a check box, encapsulating and handling all of the crossthread delegate stuff 
required to write to the checkbox label.

Just as an example of how we really use this RunState class, we have a system which validates 
addresses.  The program consists of a single form with three sections, for three high level 
processes.  The processes are Export / Address validation / import.  We use a manager class which 
"owns" the three sections of the form.  The manager class has three instances of the RunState class 
each of which communicates with the user via a checkbox.  The manager has a collection of 
supervisors (jobs) which are in some state of completion.  Each job can be partially or entirely 
exported to disk, processed through address validation and / or imported back in.  Thus each job has 
an instance of the RunState class for each of the three processes.  The manager class decides which 
jobs run and communicates with the job via the RunState class instances, telling a specific job (or 
jobs) to export, a specific job to Address Validate and a specific job (or jobs) to import.

The Supervisor's RunState class instances allows the manager to start and stop the supervisors 
(jobs) and to determine that a job is stopped.

When a job is running the program cannot close, and the form cannot close.  When the manager 
determines that all jobs are in a stopped state the check box labels tell me (the user) that nothing 
is running and I can close the form and the program.

This system is designed to run on my server 24/7.  I do have to be logged in to run it since it has 
a user interface but basically I remote desktop in to the server, start the program, and then close 
the remote desktop session leaving my user logged in.  The program just sits and runs.  I have 
address validation jobs which are scheduled out in the future and the manager loads up all the jobs 
and just watches them.  If a job becomes active, the manager starts it and monitors its completion 
through the various stages.  Using the check boxes on the form I can shut the program down cleanly, 
even if it is in the middle of a long running operation.  The RunState allows me to tell each 
section to stop and allows me to see when everything is stopped.

-- 
John W. Colby
Colby Consulting

Reality is what refuses to go away
when you do not believe in it