ApplicationExplorer Template Overview

Introduction

In terms of user interface, typical in-house “business applications” such as CRM and inventory management systems do not lend themselves readily to the user interface principles used in the more common “productivity application” such as Microsoft Word or Excel. Often, these proprietary in-house applications perform many disparate duties in a single UI. Developers have traditionally taken the (lazy) classic MDI route to create these applications. However, MDI is not the ideal UI and has been discouraged by Microsoft since as far back as 1995.

Microsoft has attempted to address this with the after-market UI Composite Block framework. However, this Patterns and Practices framework, while exhaustive, is complex and forces an application to be inextricably tied to many paradigms and rules. ApplicationExplorer strives for simplicity. In its basic form it acts as a “container” for your child windows- providing both tabbed MDI and dialog-based user interface options- without forcing you to make ANY changes to them (such as deriving them from a custom base type). While it does attempt to steer away from the complex “framework” paradigm in favor of the “starting point” template philosophy, it does contain some elements of the former via optional easy-to-use interfaces that child windows may- but do not have to- implement.

Note: This document is meant to describe the overall nature of ApplicationExplorer. For more specific details and usage examples see the Sample Code subfolder in the Application Explorer project.

Starting Points

ApplicationExplorer.vb: This is the main class where you will be entering and customizing your code as it relates to the main ApplicationExplorer window. It is a clean partial class and is fully documented. Most of the sensitive plumbing code- optionally but not necessarily modifiable- is elsewhere in the ApplicationExplorer.InternalCode.vb file.

ApplicationExplorerForm.ExampleCode.vb: This class contains several sample modes that override the code in ApplicationExplorer.vb and can be triggered by simply setting a precompiler constant (Project Properties -> Compile -> Advanced Compile Options) and demonstrates several ways you can customize the main AplicationExplorer.vb class.

Note: The entire Sample Code subfolder can be safely deleted or excluded from a project.

User Interface Design Considerations

ApplicationExplorer implements a tabbed document interface as seen in modern applications such as FrontPage and FireFox (see ChildrenOnly mode). But, it can also display a simple dialog-based UI (see SingleView mode) and a combination of dialog and tabbed documents (see MultiView mode). However, one must be mindful of the principles behind each of these UI’s. For instance, in a MultiView UI the master window (presented to the user a “pane”) becomes the “dominant” user interface. That means that the parent MDI form’s menus and toolbar actions should act on the master window and not the children.

Here are some tips for designing a user interface using ApplicationExplorer’s spectrum of modes:

ChildrenOnly:

• File|New/Open/Save can be used load items that will open as child windows.
• All windows that implement ICustomUIToolsCapable (see Advanced Customizations elsewhere in this document) will have their menus and toolbars merged into the main ApplicationExplorer window.

Figure 1 - ChildrenOnly UI Example

MultiView:

• Master windows (Views) are shown using the ShortcutBar.
• File|New/Open/Save commands should NOT be used to open any child windows nor act upon any single master window, but instead are used to open a “database” or configuration file or hidden altogether.
• Master windows that implement ICustomUIToolsCapable  (see Advanced Customizations elsewhere in this document) will have their menus and toolbars merged into the main ApplicationExplorer window. Child windows do NOT have their tools merged at all.

Figure 2 – MultiView UI Example

User Interface Modes (UIModes)

ApplicationExplorer can be set to run in several User Interface modes (see m_uiMode setting in the code). Each mode is meant to present the cleanest user interface to compliment the application’s purpose. For instance, a pure MDI solution where each window is of equivalent importance would use the ChildrenOnly mode.

ChildrenOnly

ChildrenOnly mode is a simple pure tabbed MDI user interface.

SingleView

SingleView mode is a single form or dialog-based user interface but with all the built-in benefits of ApplicationExplorer (see Menus and Commands elsewhere in this document).

MultiView

MultiView mode is an advanced 3-pane Master/Details or Outlook-esque  style UI with master windows presented as "pane" and child windows opened at its bottom or right side. MultiView supports multiple master windows and switching between them is accomplished via a “ShortcutBar” docked at the side of ApplicationExplorer.

MultiView2

MultiView2 is a 2-pane combination of MultiView and SingleView. Only one master window is presented to the user with child windows opened at the bottom or on the side.

Menus and Commands

Many of ApplicationExplorer’s menus contain built-in “Smart” functionality and do not need to be modified directly. For instance, the Edit|Cut/Copy/Paste commands automatically work across all windows and with many different controls. You can further enhance or supplant the functionality of these commands by implementing several optional interfaces in your child windows (see Advanced Customizations elsewhere in this document).

Note: ApplicationExplorer is a template. Menu commands can be freely hidden, deleted, or renamed.

Menu Commands List

Boilerplate / Customizable	Built-in Functionality

• 
• 
• 
• 
• 
• 
• 
• 
• 
• 
• 
• 
• 
• 
• 
• 
• 
• 
• 
• 
• 
• 
• 
• 
• 
• 
• 
• 
• 

Advanced Customizations

Optional Interfaces

ApplicationExplorer provides several optional interfaces that allow child windows to communicate with the ApplicationExplorerForm parent window. For instance, ICustomUIToolsCapable allows child windows to merge toolbars and menus with the main parent form. Whenever a child window becomes active, ApplicationExplorerForm inspects to see if the window implements ICustomUIToolsCapable and then queries the window for a toolstrip or menustrip control. For more details, see the Optional Interfaces subfolder in the project and some of the samples windows in the Sample Code subfolder for more details.

Notifier

Since child forms should be able to operate independently both within ApplicationExplorer and on the desktop as an overlapping window, they don’t need to be “aware” of the main ApplicationExplorer MDI parent. So how can they communicate with the main parent form to tell it to do things such as display text in the main status bar? Well, they would send out a broadcast command message using g_notifier.SendNotification. Whichever ApplicationExplorer is handling the window (there can be multiple ApplicationExplorers open) will pick up the message and act accordingly. Child windows can also use g_notifier to communicate with each other.