Controlling Multiple Forms with a Finite State Machine

• Download State Machine Source Files - 32.7 KB
• Download State Machine Executable - 28.7 KB

Introduction [toc]

A paradigm that I have successfully used to implement multiple interrelated forms is the finite state machine. It makes a few demands upon the forms and the Dispatcher. But it is simple, surprisingly efficient, and easily extensible.

For example, say that an application requires four forms:

• initialize - execute startup code.
• login - verify the user's credentials.
• order - accept a user's order.
• realize - confirm the user's order

The flow of control between these forms is depicted in the following figure. A square rectangle represents a form; a rounded rectangle represents a Button; the dotted green rectangle is the start state of the application; and the dotted red rectangle is the end state of the application.

This article describes the Dispatcher that controls the flow from one form to another and the common content of the forms themselves.

Table of Contents

• Introduction
• Table of Contents
• The Dispatcher
• The Forms
• Conclusion
• References
• Development Environment
• History

The symbol [toc] returns the reader to the top of the Table of Contents.

The Dispatcher [toc]

A finite state machine [^] is:

an abstract machine that can be in one of a finite number of states. The machine is in only one state at a time; the state it is in at any given time is called the current state. It can change from one state to another when initiated by a triggering event or condition; this is called a transition. A particular finite state machine is defined by a list of its states, and the triggering condition for each transition.

The class ApplicationState enumerates the States used by the Dispatcher and maintains the Next_State property whose value will eventually become the value of the current_state.

For the set of forms, enumerated above, the Dispatcher States are:

public enum States
    {
    NOT_SPECIFIED,              // no state yet specified

    INITIALIZE,                 // any initialization
    LOGIN,                      // accept user credentials
    ORDER,                      // accept user order
    REALIZE,                    // confirm order

    // for each new Form add new state here

    ERROR,                      // perform error processing
    LOGOUT,                     // perform LOGOUT processing
    TIMEDOUT,                   // perform TIMEOUT processing
    FINISHED,                   // perform wrap-up processing

    TERMINATE,                  // forces application exit

    NUMBER_STATES = TERMINATE
    }

Initially, the Dispatcher's current_state is set to ApplicationState.Next_State that, in turn, is initially set to States.INITIALIZE.

Each form that will be accessed by the Dispatcher is declared in the Dispatcher.

private static Form  initialize = null;
private static Form  login = null;
private static Form  order = null;
private static Form  realize = null;

Declaring the forms in the Dispatcher allows reuse of the forms, thus avoiding memory overflow. To extend the Dispatcher, additional forms are added and the ApplicationState class is modified to add the new form to the States enumeration.

At the conclusion of their processing, each form (e.g., initialize, login, order, realize, etc.) sets the value of ApplicationState.Next_State. In turn, the Dispatcher sets its current_state from the revised ApplicationState.Next_State.

The Dispatcher takes the following form:

// ************************************************ Dispatcher

public static void Dispatcher ( )
    {
    States   current_state = ApplicationState.Next_State;

    while ( current_state != States.TERMINATE )
        {
        switch ( current_state  )
            {
            case States.INITIALIZE:
                // create and open the initialize form
                break;

            case States.LOGIN:
                // create and open the login form
                break;

            case States.ORDER:
                // create and open the order form
                break;

            case States.REALIZE:
                // create and open the realize form
                break;

            case States.TIMEDOUT:
            case States.LOGOUT:
                ApplicationState.Next_State = States.FINISHED;
                break;

            case States.ERROR:
                MessageBox.Show (
                    String.Format (
                        @"Error in {0}",
                        current_state.ToString ( ) ) );
                ApplicationState.Next_State = States.FINISHED;
                break;

            case States.TERMINATE:

                break;

            case States.FINISHED:
                ApplicationState.Next_State = States.TERMINATE;
                break;

            default:

                break;
            }

        current_state = ApplicationState.Next_State;
        }

    dispose_all_forms ( );
    }

The dispose_all_forms helper method performs the task that its name implies.

The code for each of the form states takes the same form. Using the initialize Form as an exemplar:

switch ( current_state  )
    {
    case States.INITIALIZE:
        if ( initialize == null )
            {
            initialize = new Initialize ( );
            }
        if ( ( ( Initialize ) initialize ).initialize_form ( ) )
            {
            initialize.ShowDialog ( );
            }
        else
            {
            ApplicationState.Next_State = States.ERROR;
            }
        break;

For each form, the Dispatcher takes the following actions:

• Determines if the form exists (that is if the Form is null or not). If the Form is null, Dispatcher creates it.
• Invokes the initialize_form method of the Form.
• If the initialize_form method of the Form returns true, the Dispatcher invokes the Form's ShowDialog method, to display the Form as a modal dialog box; otherwise the Dispatcher will set ApplicationState.Next_State to States.ERROR.
• The Form performs its tasks and, upon completion, the form sets the value of ApplicationState.Next_State to the next state that the state machine is to process.
• The Dispatcher sets its current_state to the revised ApplicationState.Next_State.

The Forms [toc]

To use the finite state machine paradigm, there are some rather straight-forward restrictions imposed upon the content of the Forms:

• The namespace of all of the Forms must be known by the Dispatcher. In this article's software, the namespace is StateMachine across all Forms and classes.
• The Form's class constructor should be limited in its tasks. If the Visual Studio Designer is used, the constructor should only contain the InitializeComponent invocation. If the Visual Studio Designer is not used, the equivalent of the InitializeComponent invocation should occur. For the initialize form, the class constructor is:
  C#

  // ************************************************ Initialize
  
  public Initialize ( )
      {
  
      InitializeComponent ( );
      }
  

• A public method that returns a bool must be known by the Dispatcher. In all of the forms in this article's software, the method is named initialize_form. In initialize it takes the following form:
  C#

  // ******************************************* initialize_form
  
  public bool initialize_form ( )
      {
      bool  successful = false;
  
      if ( !initialize_GUI_controls ( ) )
          {
          successful = false;
          }
      else if ( !initialize_hardware ( ) )
          {
          successful = false;
          }
      else if ( !credit_card_reader_present ( ) )
          {
          successful = false;
          }
      else if ( !connected_to_printer ( ) )
          {
          successful = false;
          }
      else
          {
          successful = true;
          }
  
      if ( !successful )
          {
          close_form ( States.TERMINATE );
          }
  
      return ( successful );
      }
  

  The contents of each of the initialize_form methods is dependent upon the purpose of the individual forms (i.e., initialize, login, order, or realize).
  
  The helper method close_form, common to all forms, takes on the following form:
  C#

  // ************************************************ close_form
  
  void close_form ( States next_state )
      {
  
      ApplicationState.Next_State = next_state;
  
      this.DialogResult = DialogResult.OK;
      this.Close ( );
      }
  

  Within the initialize form, close_form is also invoked by the continue and cancel button click event handlers:
  C#

  // **************************************** continue_BUT_Click
  
  void continue_BUT_Click ( object    sender,
                            EventArgs e )
      {
  
      close_form ( States.LOGIN );
      }
  
  // ****************************************** cancel_BUT_Click
  
  void cancel_BUT_Click ( object    sender,
                          EventArgs e )
      {
  
      close_form ( States.FINISHED );
      }
  

  Note, it is within these event handlers that the next state of the finite state machine is determined.

Conclusion [toc]

This article has presented a paradigm to control multiple Forms using a finite state machine. The following figure is the flow for a real-world application that used this technique.

References [toc]

• Finite State Machine ^]

Development Environment [toc]

The software was developed in the following environment:

History [toc]