Home > Documentation > Development > 3. Designing Winforms views engine

Part 3. Designing a Windows Forms views engine

Introduction
Requirements
    User control views
    MDI form views
    Modal form views
    Different views with same type
    Notifications to views
    Base views implementations
Implementation
    General classes
    WinformsViewsManager class
Summary

Introduction

In the previous articles (parts 1-2) we have introduced a views manager concept for isolating the presentation mechanism of the MVP framework. This article describes the development of the real-life Windows Forms views manager and its attendant classes for our MVP framework.

The only responsibility of a views manager is switching between views. This might seem easy at first sight, however it becomes more tricky as we delve deeper into the presentation specifics and take into account pecularities of the views mechanism. For example in the previous part we have already created a simple Windows Forms views manager, however it is not able to treat user controls as views, neither it can handle dialogs or MDI forms.

That is why for creating a fully functional views manager we need to thoroughly analyze the corresponding presentation mechanism and construct requirements to that views manager. These requirements will typically include the description of possible view types, thier interrelation and so on. Thus our first step is building requirements to the constructed views manager. We will assume that the basic requirements of working with simple forms are already implemented (see the end of the previous article where we constructed a simple forms views manager) and will proceed to the more advanced demands.

Requirements

User control views

The starting point for building the first requirement will be the fact that a user might want to have more than one interaction point on his screen at a moment. Although separate, these views may be logically coupled, which discourages us from placing them onto different forms. A more plausible (and popular in modern GUIs) solution is putting views into different parts of a single form. For instance an orders view and an order lines view can be displayed as parts (e.g. upper and lower halfs) of a common window.

In .NET Windows Forms technology such views are implemented as user controls. They are designed separately, but finally are placed together and arranged on a single form. Thus in general our requirement sounds like this: UserControl class descedants may be used as views.

To express this requirement in a more precise form let us decide how a developer would mark a particular user control to be used as a view. Here two alternatives are possible: 1) Let the framework create an instance of the user control, 2) Create the user control istance manually and place it on some view. If a developer chooses 2 (to create an instance himself) then how will the framework distinguish the user control-view from an ordinary user control? The answer is quite obvious here: a user control class should implement the IView interface to make the MVP framework treat it as a view. So here is how the first use case looks:

User control views
    User: Create a UserControl sublass which implements the IView interface.
          Place its instance on some view. Assign a ViewName property to it.
    System: Find this user control and initialize it (tie to the controller,
            register in the system and so forth)

Here we have included the view name assignment to the user's actions. That is because a view initialization requires the knowledge of that view's name.

However the view registration and initialization are not the only necessary activities. We should also consider how a user control view should be activated. Unlike forms user controls cannot be activated, instead they have a Focus() method which moves in the input focus. However focusing a user control is of little use if the parent form is inactive, therefore we should also assure the parent form activation:

Activating a user control view
    User: Trigger a user control view activation (via Navigator.Naviagate(.).
    System: Activate the parent form and Call the Focus() method on the
            user control view.

A manual user control view activation is possible too when a user clicks somewhere inside that user control. As a response the system should perform navigation to this view:

Manual user control view activation
    End user: Click on a user control view (or somehow else move the focus
              inside it).
    System: Perform the navigation to this view.

MDI form views

Another kind of view we might want to use is the MDI form. Although slightly out of fashion nowdays, MDI forms may prove useful in various applications. That is why the next requirement will concern the usage of MDI forms as views.

Applying MDI forms in .NET is simple: the only thing needed is to specify the parent form by setting its isMdiContainer property to true and to set MdiParent property for all child forms. We could link child forms to the parent form instances by ourselves, however it is not as easy since the MVP framework and particulary the views manager itself creates forms and holds their instances. The better approach is to somehow tell the framework which views should act as MDI parents, and which ones should be their children. A good way of doing so is applying a .NET attribute with necessary parameters to the view type, like this: [WinformsView("ChildView", typeof(MainTask), MdiParent = "ParentView")]. So here is the next use case:

MDI form views
    User: Equip the form type with a WinformsView attribute with MdiParent
          or isMdiParent named parameters. Then at some point navigate to
          the corresponding view.
    System: Initialize the view as an MDI parent or child as specified.

With respect to the view activation mechanism MDI forms behave the same way as simple forms do. So let us turn to the next requirement.

Modal form views

Modal forms (dialogs) are very useful if we want a user to interact with only one form until he closes it. In .NET a form modality depends on the way how it is shown. Form.Show() displays form in an ordinary (not modal) state, while Form.ShowModal() displays it as modal. Anyway it is a job of the views manager to show forms, and we should somehow indicate it which forms to display as modal. As in previous requirement we may use a .NET attribute with a named parameter ShowModal: [WinformsView("ChildView", typeof(MainTask), ShowModal = true)]. This is the use case:

Modal form views
    User: Equip the form type with a WinformsView attribute with a ShowModal
          named parameter. Then navigate to the corresponding view.
    System: Show the form as modal by calling Form.ShowDialog().

Different views with same type

Applying the [View("ViewName", ...)] or [WinformsView("ViewName", ...)] attribute to a view type we specify the concrete view type for the interaction point with "ViewName" view name. But what if another view should be of the same type? The answer is straightforward: allow users to specify several [(Winforms)View] attributes with different view names for a single view type:

Different views with same type
    User: Equip a view type with several (Winforms)View attributes.
    System: Treat this as descriptions of different views with the
            same view type.

Notifications to views

It may be important for a view to react in a particular way when it gets (de)activated. For example a view may disable some controls on it when it loses focus. A view may also need to perform some initalization steps when it is activated for a first time. For this we need notifications to be sent to views whenever they are (de)activated or initialized (activated for a first time).

For handling a view (de)activation we might watch the change of the Task.CurrentViewName property. The view initialization can be done in the IView.Controller setter method. Much more straightforward, however, is to have explicit Activate(bool activate) and Initialize() operations, invoked by the views manager. These operations may be placed in a separate INotifiedView interface.

Notifications to views
    User: Invoke navigation to/from a view that implements INotifiedView
          interface.
    System: Call Activate(true/false) on that view. Call Initialize() on
            it if activated for a first time.

Base views implementations

Each form or user control we want to be a view should implement the IView interface. It would be convenient if the framework provides developers with base form and user control classes which already implement IView and even INotifiedView interfaces. For example these could be WinFormView and WinUserControlView classes.

Now we have finished with building requirements and will proceed to the implementation phase.

Implementation

General classes

First we will implement the WinformsView attribute with optional parameters as defined in the "MDI form views" and "Modal form views" use cases:

[AttributeUsage(AttributeTargets.Class, AllowMultiple = true)]
public class WinformsViewAttribute : ViewAttribute
{
    ...
    public WinformsViewAttribute(Type taskType, string viewName)
        : base(taskType, viewName) { }

    public WinformsViewAttribute() { }

    public bool ShowModal
    ...
    public bool IsMdiParent
    ...
    public string MdiParent
    ...
}

In the previous article we have introduced the DefaultViewInfosProvider class for processing [View] attributes. For each met [View] attribute it created a ViewInfo instance. Similarly we should treat [WinformsViewAttribute] attributes, except for that WinformsViewInfo objects should be created instead of simple ViewInfo objects.

public class WinformsViewInfosProvider : DefaultViewInfosProvider
{
    protected override ViewInfo newViewInfo(Type viewType, ViewAttribute viewAttr)
    {
        WinformsViewInfo viewInfo = new WinformsViewInfo(viewType);
        if (!(viewAttr is WinformsViewAttribute)) return viewInfo;

        viewInfo.IsMdiParent = (viewAttr as WinformsViewAttribute).IsMdiParent;
        viewInfo.MdiParent = (viewAttr as WinformsViewAttribute).MdiParent;
        viewInfo.ShowModal = (viewAttr as WinformsViewAttribute).ShowModal;
        return viewInfo;
    }
}

public class WinformsViewInfo : ViewInfo
{
    public WinformsViewInfo(Type viewType) : base(viewType)
    { }

    public bool ShowModal
    ...
    public bool IsMdiParent
    ...
    public string MdiParent
    ...
}

Notice that "AllowMultiple = true" is specified for the WinformsViewAttribute (as well as for the ViewAttribute). By doing so we meet the "Different views with same type" requirement.

One more simple requirement we will implement before proceeding to the more complicated ones is the "Base views implementations" requirement. For that we will create Form and UserControl descedants and make them implement IView and IWinformsView interfaces in a simpliest way: with the use of virtual properties with backing fields and empty virtual methods:

public class WinFormView : Form, IView, IWinformsView
{
    // IView and IWinformsView implementations with virtual
    // methods and virtual properties with backing fields
    ...
}

public class WinUserControlView : UserControl, IView, IWinformsView
{
    // IView and IWinformsView implementations with virtual
    // methods and virtual properties with backing fields
    ...
}
\

WinformsViewsManager class

WinformsViewsManager class will inherit from ViewsManagerBase - a simpliest IViewsManager implementation:

public class WinformsViewsManager : ViewsManagerBase
    ...    
    public override void ActivateView(string viewName)
    {
        IView view = FindOrCreateView(viewName);
        NotifyViewsOnActivation(view);
        if (view is Form)
            ActivateFormView(view);
        else if (view is UserControl)
            ActivateUserControlView(view);
    }

In the ActivateView method above we do the following: get already created view from an internal hash or create a new one and activate this view in a manner depending on the view kind. Between these two steps we notify views about their (de)activation in the NotifyViewsOnActivation(...) method - this is required by the "Notifications to views" use case:

public class WinformsViewsManager : ViewsManagerBase
    ...
    private void NotifyViewsOnActivation(IView activatedView)
    {
        IWinformsView prevActiveWFView = prevActiveView as IWinformsView;
        if (prevActiveWFView != null) prevActiveWFView.Activate(false);
        IWinformsView winformsView = activatedView as IWinformsView;
        if (winformsView != null) winformsView.Activate(true);
        prevActiveView = activatedView;
    }

FindOrCreateView(...) method instantiates views if they do not exist yet. Type information is taken from the appropriate WinformsViewInfo object. Then, depending on the view type (form or user control), the corresponding view initialization method is invoked:

public class WinformsViewsManager : ViewsManagerBase
    ...
    private IView FindOrCreateView(string viewName)
    {
        IView result = views[viewName] as IView;
        if (result == null)
        {
            WinformsViewInfo viewInf = ViewInfos[viewName] as WinformsViewInfo;
            result = CreateHelper.Create(ViewInfos[viewName].ViewType) as IView;
            result.ViewName = viewName;
            if (result is UserControl)
                InitializeUserControlView(result as UserControl);
            else if (result is Form)
                InitializeFormView(result as Form, viewInf);
        }
        return result;
    }

Below are the methods for user control and form initialization:

public class WinformsViewsManager : ViewsManagerBase
    ...
    protected virtual void InitializeUserControlView(UserControl userControlView)
    {
        InitializeView(userControlView as IView);
        userControlView.Enter += new EventHandler(view_ActivatedManually);
        NotifyInitialize(userControlView as IView);
        InitializeChildViews(userControlView);
    }

    protected virtual void InitializeFormView(Form form, WinformsViewInfo viewInf)
    {
        InitializeView(form as IView);
        form.Activated += new EventHandler(view_ActivatedManually);
        form.IsMdiContainer = viewInf.IsMdiParent;
        string mdiParent = viewInf.MdiParent;
        if (mdiParent != null)
            form.MdiParent = views[mdiParent] as Form;
        NotifyInitialize(form as IView);
        InitializeChildViews(form);
    }

Both these methods use the InitializeView(...) and NotifyInitialize(...) methods which contain common initialization steps regardless of the view type. InitializeView(...) binds together a view with its controller. NotifyInitialize(...) sends an "Initialize" message to the view accordingly to the "Notifications to views" requirement:

public class WinformsViewsManager : ViewsManagerBase
    ...
    private void InitializeView(IView view)
    {
        views[view.ViewName] = view;
        view.Controller = Navigator.GetController(view.ViewName);
        view.Controller.View = view;
    }

    private void NotifyInitialize(IView view)
    {
        INotifiedView winformsView = view as INotifiedView;
        if (winformsView != null)
            winformsView.Initialize();
    }

Note that the InitializeFormView(...) method contains code specific to views represented as forms: if needed, it makes a form MDI child or parent, thus satisfying the "MDI form views" requirement.

InitializeChildViews(...) - is a method that searches for user control views inside a form or another user control view. The search is done recursively, for found user control views the user control-specific InitializeUserControlView(...) method is called. By doing so we implement the "User control views" use case:

public class WinformsViewsManager : ViewsManagerBase
    ...
    protected void InitializeChildViews(Control container)
    {
        foreach (Control c in container.Controls)
        {
            IView childView = c as IView;
            if ((childView != null) && (!IsInitialized(childView)))
                InitializeUserControlView(childView as UserControl);
            else
                InitializeChildViews(c);
        }
    }

By handling the Enter event of user controls we meet the "Manual user control view activation" requirement:

    private void view_ActivatedManually(object sender, EventArgs e)
    {
        Navigator.TryNavigateToView((sender as IView).ViewName);
    }

The last two methods left are the view activation methods ActivateFormView and ActivateUserControlView. The former shows and makes active a form view, taking into account that it could be configured as modal (and thus meeting the "Modal form views" requirement):

public class WinformsViewsManager : ViewsManagerBase
    ...
    private void ActivateFormView(IView view)
    {
        Form form = view as Form;
        WinformsViewInfo viewInf = ViewInfos[view.ViewName] as WinformsViewInfo;
        if (viewInf.ShowModal)
        {
            if (!form.Visible) form.ShowDialog();
        }
        else
        {
            form.Show();
            form.Activate();
        }
    }

ActivateUserControlView(...) method not only focuses the user control but it firstly activates the parent of this control, thus implementing the "Activating a user control view" use case:

public class WinformsViewsManager : ViewsManagerBase
    ...    
    private void ActivateUserControlView(IView view)
    {
        UserControl uc = view as UserControl;
        uc.Focus();
        uc.FindForm().Show();
        uc.FindForm().Activate();
    }

Summary

Throughout this article we have been building a comprehensive Windows Forms views engine for the Model-View-Presenter framework. We have started with a list of requirements for the future views engine and then implemented these requirements in the WinformsViewsManager class and other satellite classes. As a result these classes comprise a fully-functional views engine suitable for various MVP applications with Windows Forms-based UI. However it is not restricted to further extend this views engine tailoring it for specific needs.