GUI as a finite state machine

To implement application's GUI I would like to have all the logic to go from one form to another centralized. This GUI manager will behave as a finite state machine. Although I think I have seen this kind of implementation somewhere, I can't find a design pattern that matches with this kind of solution.

A form will look like this:

public class Login : Form
{
    ...

    private void EnterButton_Click()
    {
        ...

        string user = loginTextBox.Text;
        string password = passwordTextBox.Text;
        bool isValid = SecurityManager.CheckUserLogin(user,password);
开发者_StackOverflow
        GUIManager.FormEnd(FormLogin,new LoginData(user, pass, isValid));
    }

    ...
}

And the GUI manager will do something like this:

public class GUIManager
{
    ...

    public void FormEnd(FormType type, FormData data)
    {
        switch (type)
        {
            ...
            case FormLogin:
                LoginData ld = (LoginData)data;
                if (ld.Valid)
                {
                    m_loginForm.Hide();
                    m_mainForm.Show();
                }
            ...
        }
    }

    ...
}

Reaching this point I have the following questions: is there a desing pattern that formalizes this idea? If there is, does .NET support it somehow? If there isn't, does it sound like a good implementation idea? Thanks!

The State design pattern describes how to implement a finite state machine.

There are many, slightly different design patterns to control screens in UI, but I think that the Application Controller design pattern fits what you are trying to do.

It's a great idea! So great, in fact, that it's been done before and is probably the most common pattern used in extensible application development (think of IDEs like Visual Studio, Eclipse and the like).

One example, SCSF (which leverages CAB), from the MS Patterns and Practices Group, uses this pattern out-of-the-box to construct pluggable and extensible composite applications in both WinForms and WPF. The actual pattern it uses involves construction of hierarchical state machines called WorkItems that control usecases and flow through the application. I'd look into how the Patterns and Practices guys did it before I implement it as my own brainchild. I've used it on many occasions and it's well worth it.

In the Java world you can think of a Struts or JSF application as an FSM (this event on this page/state takes us to that page/state.

When modelling the flows in a traditional web-based UI I did find using FSMs to be an extremely useful analysis tool. You can very quickly capture the essence of the application's behaviour. There was pretty much a one-to-one correspondance between page and state. I would have a state model and associated data models.

Now we have richer UIs exploiting AJAX the correspondance between application states and "pages" is less obvious. However you can still reason about the application's behaviour: here the user is doing this, when they have finished thay can take actions X or Y and then they are able to do that. So the states, events and transitions do still exist it's just that their representaiton is a little more "virtual".