Jim Lawrence
accessd at shaw.ca
Sat Oct 29 11:07:37 CDT 2011
It sounds very impressive as a piece of software that took months (years) to design and debug. I would assume you will be marketing this product soon. ;-) Question: is the application taking advantage of the new "parallelism" presented in VS 2010 or is it just using multi-threading? Jim -----Original Message----- From: dba-vb-bounces at databaseadvisors.com [mailto:dba-vb-bounces at databaseadvisors.com] On Behalf Of jwcolby Sent: Saturday, October 29, 2011 8:31 AM To: VBA Subject: [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 _______________________________________________ dba-VB mailing list dba-VB at databaseadvisors.com http://databaseadvisors.com/mailman/listinfo/dba-vb http://www.databaseadvisors.com