Document-Based Applications: SDI/MDI Applications

	Document-Based Applications: SDI/MDI Applications

SDI and MDI Fundamentals

Introduction

A single-document interface, SDI, is an application primarily made of a form equipped with a menu. An example is Notepad:

Notepad

In some cases, an SDI can also have a toolbar and/or a status bar. Here is an example from Microsoft Works Spreadsheet:

Microsoft Works

All these features are left to the programmer to add and configure.

Although Notepad is text-based, an SDI can be any type of application: text, graphics, spreadsheet, anything. Therefore, to create an SDI, start from a normal form, add a menu to it, and configure it to do what you want.

To create a document using an SDI, the user launches the application. The SDI then presents a rectangular window with one frame and the inside is the document the user will use. In most cases, the application itself creates the document. The user can work on it and do whatever the application allows. To create another document of the same type, the user must open another instance of the application.

MDI Fundamentals

A multiple-document interface, MDI, is an application that primarily has a form and a menu. Some, if not most, MDIs also have one or more toolbars and/or a status bar. Here is an example:

Multiple-Document Interface

Like a normal application, to use an MDI, the user must launch it. In some cases, when the application starts, it is empty; that is, no document is created and the title bar displays a caption, usually the name of the application. Usually, there are steps the user must follow to create a document. In some other cases, when the application is launched, it automatically creates a document. A document resides inside the parent frame of the application. That is, a child document can use only the area reserved for it. The child document has its own system icon, its own title bar, and its own system buttons (Minimize, Maximize/Restore, and Close).

To use the whole area, the user can maximize the child document. When this is done, the child merges its title bar with the parent's. The new caption of the title bar becomes made of the text of the parent, followed by -, and followed by the caption the child window was using. The system buttons of the child document display under those of the parent frame:

MDI

Once a document has been created, the user can use it. Normally, the application must give the user the ability to create other documents while still using the application. If many documents have been created, all of them are confined to the frame of the parent:

Multiple Document Interface

The user can maximize the child forms. If so, the document that was in front occupies the whole area devoted to child documents. The other child forms stay in the back but become invisible.

One of the differences between an SDI and an MDI is that, because the child document and the MDI application don't share a frame, the user can close the child document and keep the application open.

Creating an MDI Application

As mentioned already, there is nothing magical with creating an SDI application. You start with a form, add a menu to it, and specify what the application should allow a user to do with a document. As we will see, an MDI requires more steps.

You start an MDI application with a normal form. Here is an example:

open System
open System.Windows.Forms

let commonParent : Form = new Form()

[<STAThread>]
[<EntryPoint>]
let main argv = 
    Application.Run commonParent
    0

The primary form of an MDI application is referred to as the parent or MDI container. It provides the frame inside of which the documents will reside. To provide this functionality, the Form class is equipped with a Boolean property named IsMdiContainer:

member IsMdiContainer : bool with get, set

Therefore, after creating the first form of your application, to indicate that it acts as the main frame, set this property to true. Here is an example:

open System
open System.Drawing
open System.Windows.Forms

let commonParent : Form = new Form()

commonParent.IsMdiContainer <- true

[<STAThread>]
[<EntryPoint>]
let main argv = 
    Application.Run commonParent
    0

This would produce:

Multiple-Document Interface

The primary characteristic of an MDI is that it contains other forms. These forms must be created and made available to the parent. Each form can be created using a predefined form or you can programmatically create one by declaring an object of type Form. To allow you to specify that a form has a parent and will act as a child, the Form class is equipped with a property named MdiParent. This is a read-write property. The set accessor indicates what form acts as this one's parent. To provide this information, assign the main form this form's MdiParent. After doing this, you can display the form when you are ready, by calling its Show() method. Here is an example:

open System
open System.Drawing
open System.Windows.Forms

let commonParent : Form = new Form()

commonParent.IsMdiContainer <- true

let frmChild : Form = new Form()
frmChild.MdiParent <- commonParent

frmChild.Show()

[<STAThread>]
[<EntryPoint>]
let main argv = 
    Application.Run commonParent
    0

This would produce:

Multiple-Document Interface

MDI Characteristics

Introduction to the Children of an MDI

When you create an MDI application, you must make sure you provide your users with the ability to create documents. In fact, probably one of your first assignments is to make sure the user can create as many documents as necessary. As the documents are created, you need a way to programmatically keep track of the child forms. For example, you can store the documents in a collection. To assist you with this, the Form class is equipped with a property named MdiChildren, which is a read-only array. Each element of the MdiChildren[] array is of type Form. Therefore, to access a child form of an MDI application, you can pass an index to this property.

The Layout of Child Forms

Based on the standards defined in the operating system, as child forms are created in an MDI application, they are positioned each on top of the previous one but below the next one. The arrangement uses a 3-D coordiniate system whose origin is on the lower-left corner of the parent's frame just under the title bar (or the menu, if any; or the toolbar, if any), with the Z axis moving from the monitor towards you:

Layout

The operating system allows the user to choose among different arrangements. For example, you can position the documents as vertical columns, as horizontal rows, or as tiles. To support this, the Form class is equipped with a method named LayoutMdi. Its syntax is:

member LayoutMdi : 
        value:MdiLayout -> unit

The LayoutMdi() method takes an argument that is a member of the MdiLayout enumeration. The members of this enumeration are Cascade, TileHorizontal, TileVertical, and ArrangeIcons.

Activating a Child

In most MDI applications, a user can create as many documents as necessary. This also means that the application can hold many child forms. To access a child form, the user can click its title bar. You can also provide options on a menu item named Window that would display a list of open documents.

When a child window is activated, it fires an event named MdiChildActivate:

member MdiChildActivate : IEvent<EventHandler,
    EventArgs>

The MdiChildActivate event is of type EventArgs.

The document that is currently active has a brighter title bar. To identify this document, the form has a property named ActiveMdiChild:

member ActiveMdiChild : Form with get

This read-only property allows you to know what document is the current active one. This property is of type Form, which means that it produces a Form object. When you enquire about this property, if its value is null, this means that there is no current active document.

If the value of the ActiveMdiChild property is not null, a document is active and you can use it.

Arranging the Minimized Children

In an MDI application, if the user doesn't want to display a document but doesn't want to close it, he can minimise the window. In the same way, the user can minimize as many child forms as necessary. When a child form has been minimized, it shows a button in the lower part of the parent. The buttons of the other minimized child forms are usually positioned next to each other:

Minimized Buttons

The user can move the buttons at will:

Minimized Buttons

A user can also close the child form using the Close button of its minimized button. At one time the minimized buttons may display as a "mess". To let you rearrange them, call the LayoutMdi method of the Form class and pass the argument as ArrangeIcons. When you do this, the application will visit all buttons, if any, that represent minimized child documents, and position them from the left to the right, adjacently.