[
Editor's Update - 1/20/2006:
This article refers to a beta version of Visual Studio 2005. An updated version of the article, reflecting features found in the final release of Visual Studio 2005, can be found at Smart Clients: Craft A Rich UI For Your .NET App With Enhanced Windows Forms Support.]
Draft a Rich UI
Ground Rules for Building Enhanced Windows Forms Support into Your .NET App
Chris Sells and Michael Weinhardt
This article is based on prerelease versions of Visual Studio 2005 and the .NET Framework 2.0. All information contained herein is subject to change.
This article discusses:
- Productivity-focused updates in Visual Studio 2005
- Resource and settings management improvements
- Flexible control layout and new strip controls
- Data binding
|
This article uses the following technologies:
.NET Framework 2.0, Visual Studio 2005
|
Contents
Since we last looked at Windows
® Forms 2.0 in May 2004, Microsoft has renamed, improved, and added a considerable number of features. The features discussed in this article are from the December 2004 Community Technology Preview, so you can definitely expect some things to change in the final release. (For our first article on Windows Forms, see
Craft a Rich UI for Your .NET App with Enhanced Windows Forms Support.)
A Windows Forms project is the gateway to exploring all the new features, and even the gate has been updated in the latest drop. The new default template-generated layout is shown in Figure 1.
Figure 1 Default Generated Windows Forms Projects
Much of the new project layout is focused on removing unnecessary code from the default wizard-generated forms, leaving a trimmed-down version that looks like this for C#:
// Form1.cs
partial class Form1 : Form {
public Form1() {
InitializeComponent();
}
}
Visual Basic
® spent a little more time at the code-trimming gym:
' Form1.vb
Public Class Form1
End Class
If you've used previous versions of Visual Studio
®, you might be wondering where the InitializeComponent implementation went. All Windows Forms designer-managed form code such as the InitializeComponent implementation has been migrated to a new file, FormName.Designer.cs or FormName.Designer.vb, as shown in
Figure 1. To split the class across two physical files, the designer takes advantage of new language support for partial classes:
' Form1.vb (Developer-Managed)
Public Class Form1
End Class
' Form1.Designer.vb (Designer-Managed)
Partial Public Class Form1
Inherits System.Windows.Forms.Form
...
Private Sub InitializeComponent()
...
End Sub
...
End Class
Here's the C# equivalent:
// Form1.cs (Developer-Managed)
partial class Form1 : Form {...}
// Form1.Designer.cs (Designer-Managed)
partial class Form1 {
...
private void InitializeComponent() {...}
...
}
If you're used to C#, you might also wonder where the application entry point (static Main method) has gone. Because Main isn't related to any specific form, it's also been moved to its own file, Program.cs, as shown here:
// Program.cs
static class Program {
/// <summary>
/// The main entry point for the application.
/// </summary>
[STAThread]
static void Main() {...}
}
By default, Visual Basic 2005 projects are configured to launch Form1 on application startup. If necessary, a custom Shared Sub Main can be specified as the application entry point. For developers, this code separation means you only have to write the code needed to address the specific problem. From a Windows Forms Designer point of view, separating InitializeComponent protects you from inadvertently tampering with it and potentially causing irreparable damage to your form.
Project Configuration
Windows Application projects also include new folders to manage project configuration. They are My Project for Visual Basic and Configuration for C#. Duncan Mackenzie covers My Project in his detailed article at
Navigate the .NET Framework and Your Projects with "My", so we'll just take a look at the C# side of things here.
Figure 2 shows the result of double-clicking a project's Configuration folder.
Figure 2 C# Project Property Editor
Most of the configuration settings from previous versions of Visual Studio can be found here, although Resources and Settings are new. Exposing project configuration via a designer-managed editor instead of a modal dialog makes them more accessible; project configuration can be kept open constantly and accessed with only a single click of a Visual Studio 2005 file tab.
Improved Resource Management
A good deal more has happened to project resources than simply exposing them via a tab. For starters, the Resource Designer has been given a much needed facelift, the major benefits being improved management and the WYSIWYG ability to see what your resources look like at design time, as illustrated in Figure 3.
Figure 3 Visual Studio 2005 Resource Editor
The new Resource Designer allows you to add new and existing files through a variety of mechanisms, including the dropdown list shown in Figure 3, pasting from the Clipboard, and dragging and dropping. You can even drag strings from sources like Microsoft Word, saving you extra typing where string data already exists.
Whichever mechanism you use to add resources, they are automatically added to one of several categories, including Strings, Images, Icons, Text Files and Sound Files. Another category, Other, holds extra resource data such as component-defined serialization of design-time data. You can view each category by changing the value of the aptly named Categories selection. Each category offers more granular views. For example, you can view all resource types other than strings through Details, List, or Thumbnail view.
Beneath the surface, the Resource Designer persists resource data to the new default Resources resource (.resx) file contained within the Configuration project folder, and works hard to make your resource programming experience as simple as resource management is now. Consider what was previously required to retrieve a string resource from your code:
// Load string resource from project resource file
Assembly assem = Assembly.GetExecutingAssembly();
ResourceManager resman = new ResourceManager("MyApp.Resource1", assem);
string myStringResource = resman.GetString("MyString");
Now consider the simplified and strongly typed approach enabled by Visual Studio 2005:
// Load strongly typed string resource
string myString = Configuration.Resources.MyString;
The Resource Designer exposes every resource you add to your project's resources as a strongly typed, static (shared) property from a resource editor-generated managed class called Resources that lives within the ProjectName.Configuration namespace. These properties are generated after either the project is rebuilt or after you run the custom tool associated with the .resx file to generate the class: ResXFileCodeGenerator. Now any type of resource including icons, images, and sounds is as easy to retrieve as a string:
// Strongly typed resources of all kinds
Icon icon = Configuration.Resources.MyIcon;
Image image = Configuration.Resources.MyImage;
MemoryStream sound = new MemoryStream(Configuration.Resources.MySound);
Currently, only a default Windows Forms project's resource file generates a strongly typed resource class by default. If you want the same support for additional .resx files, you'll need to set their Custom Tool property to ResXFileCodeGenerator.
Improved Settings Management
Like resources, settings have a custom editor that allows you to add typed settings to one of two scopes: read/write user settings and read-only application settings. User settings can change frequently, while application settings, like database connection strings, are expected not to change once an application is deployed. Application settings are persisted to an application's configuration file (applicationName.exe.config). Figure 4 shows how you can use the Settings Designer to set both user and application settings.
Figure 4 Visual Studio 2005 Settings Editor
The Settings Designer generates a Settings class (located in the ProjectName.Configuration namespace), from which it exposes each setting as a per-instance property of the type specified. Application settings are exposed as read-only properties while User settings are exposed as read/write properties. Either way, properties can be programmatically inspected or updated via a generated static (shared) Value property:
// Inspect an Application-scoped setting
string appSetting = Configuration.Settings.Default.MyAppSetting;
// Update a User-scoped setting
Configuration.Settings.Default.MyUserSetting = "myNewUserSetting";
This support offers the same great benefits you would get by using strongly typed resources, especially when ad hoc settings processing is all you need.
Since users expect their settings changes to be saved from one application session to the next, settings need to be loaded at the beginning of each new session and saved at the end of each. Half of this job is taken care of for you: application and user settings are automatically loaded when first used in a new session. To save them at the end of each session, you have to make a single call to the Save method, which is exposed to your code indirectly via the Settings class:
void OptionsForm_FormClosing(object
sender, FormClosingEventArgs e) {
// Save user settings for next time
Configuration.Settings.Default.Save();
}
A suitable location for this code would be the FormClosing event handler. User settings are persisted to a Windows Logo-compliant location within the file system on a per user basis in a file named
user.config, where
user is the current user's profile name. On a typical system, here's the path to that file:
c:\documents and settings\username\Local
Settings\Application Data\company name\product
name_hash\product version\
Sometimes users change settings to values they are not happy with and then can't remember what the previous defaults were. Fortunately, there are two simple recovery options. First, you can provide a mechanism for users to revert to the last saved settings by calling the Settings object's Reload method, like so:
void reloadSettingsButton_Click(object sender, EventArgs e) {
// Revert back to last saved user settings
Configuration.Settings.Default.Reload();
}
This loads the settings from the same persistent store used when the application was first started. If user settings are changed beyond all recognition, you can revert to the default user settings, which are the initial values entered into the Settings Designer. To retrieve them, simply call the Settings object's Reset method:
private void resetButton_Click(object sender, EventArgs e) {
// Revert back to default installed user settings
Configuration.Settings.Default.Reset();
}
User settings are managed in such a way that if the user.config file is deleted the default values for those settings are loaded into the next application session, which is the same as calling the Reset method. The settings subsystem comes with more exotic capabilities, including upgrade support, settings profiles, and even the ability to create custom settings providers—a feature that would allow you to save user settings to a Web service, for example.
System.Windows.Forms.Form
It's also worth your time to explore the full gamut of enhancements to System.Windows.Forms.Form, the number one class in Windows Forms app development. The changes to System.Windows.Forms.Form have been made in accordance with the prime objective of the .NET Framework 2.0: productivity. Figure 5 lists key new members that will simplify your life. Of particular interest are the enhancements to layout capabilities.
Figure 5 System.Windows.Forms.Form Key Enhancements
| Member |
Type |
Description |
| Flash, StopFlash |
Methods |
Flashes your form's taskbar button, window title bar, and window StopFlash border. Inactive forms flash to notify the user that something has happened. By default, calling Form.Activate will flash both taskbar button and window title three times. |
| ValidateAll |
Method |
Validates all controls within a scope specified by the ValidateFlags enum, including All, Enabled, ImmediateChildren, Selectable, TabStop, and Visible. Calling ValidateAll passing in a ValidateFlags value defaults to Selectable. |
| AutoValidate |
Property |
Can be one of three values: Yes (default), No, or Inherits. No prevents any controls with CausesValidation set to true from firing their Validating and Validated events, which avoids focus being retained in an invalid control. |
| FormClosing, FormClosed |
Events |
Use instead of Closing and Closed when a form is closed; both offer more detailed information. |
| ResizeBegin, ResizeEnd |
Events |
If handling the Resize event is not granular enough, ResizeBegin and ResizeEnd should give more flexibility. |
Form and Control Layout
Both System.Windows.Forms.Form and the Windows Forms Designer have been enhanced to offer richer support for form and control layout management. The whole process has been simplified dramatically.
Snap-lines, Beta 1 Style In our previous article, we showed how snap-lines simplify the task of aligning controls with horizontal and vertical edges; the designer redlines snap-lines with a third snap-to feature that helps align controls to common text baselines. Figure 6 shows top-edge, text baseline, and bottom-edge snap-lines in action.
Figure 6 Alignment
Padding and Margins Snap-lines allow you to quickly align your controls horizontally and vertically as you drag them around a form. Besides being aligned to one another, controls also need to be nicely spaced out. That's the job of two new properties: Padding and Margin. Padding is the internal distance in pixels from the edge of a form or control's client area that child controls (and also text, images, and so on) can't intrude on. A margin is the external distance in pixels from the edge of a control that other controls can't intrude on. When you drag controls around a form, the Windows Forms Designer will display a dotted line between controls and the form when the distance between them is the sum of both their Margins and Padding (where relevant). Figure 6 shows the dotted line between Label and TextBox controls. Figure 7 shows how margins and padding are used to determine when controls are correctly spaced. Both Padding and Margin properties can be specified at once for all edges, or specified edge by edge.
Figure 7 Margins and Padding
Complex Layout Scenarios For more complex layout scenarios, such as resizable dialogs with nontrivial numbers of controls, you'll need an advanced layout engine, an infrastructure for building specialized layout controls to handle more elaborate layout needs. Two layout control implementations come with Windows Forms 2.0, TableLayoutPanel and FlowLayoutPanel, both of which borrow from HTML-style layout capabilities. Both are panel-like controls designed to host other controls while simultaneously applying their particular layouts at both design time and run time.
TableLayoutPanel TableLayoutPanel allows you to define rows and columns that can be configured to size automatically in one of three ways: AutoSize, Percent, and Absolute. Rows and columns can also be merged and physically resized through the Windows Forms Designer. Each cell can only contain one control whose position within the cell is determined by docking and anchoring. Figure 8 shows an example of how the TableLayoutPanel might be used.
Figure 8 TableLayoutPanel Control
Figure 8 also shows both the OK and Cancel buttons hosted in a nested TableLayoutPanel. Since TableLayoutPanel can host only a single control in each cell, you might find nested tables a useful technique. Alternatively, you could utilize TableLayoutPanel's support for merged columns and rows.
FlowLayoutPanel If tabular layout is not what you're after, the FlowLayoutPanel might be more suitable, especially when you want a form and its controls to resize the way HTML Web pages do. You can tell a FlowLayoutPanel the direction in which the controls should be moved during form resize by setting its FlowDirection property to one of four values: LeftToRight, TopDown, RightToLeft, or BottomUp.
As with Web pages, a FlowLayoutPanel may be resized to be so small that controls simply cannot be moved any more, leaving them partially or fully covered by either vertical or horizontal edges of the FlowLayoutPanel, or both. Setting its AutoScroll property to True provides vertical and horizontal scrollbars as needed.
Strip Controls
Besides the layout panels, some of the new controls you saw in our previous article have undergone significant enhancements. One of the most significant is reminiscent of the movie Gremlins; someone at Microsoft obviously fed the WinBar after midnight because it has since multiplied into a complete suite of "strip" controls, including MenuStrip, ToolStrip, StatusStrip, and ContextMenuStrip (see Figure 9).
Figure 9 Strip Controls
The new strip controls improve on MainMenu, ToolBar, StatusBar, and ContextMenu in several key ways, including:
- A consistent API to all strip controls
- Improved design-time experience
- Allowing adjacent strip controls to be repositioned with respect to one another, as well as repositioned to the top, right, bottom, and left of the host form's client area
- Contemporary look of Office 2003 and Windows themes
- Ability to host a rich set of child controls, such as dropdown lists, labels, menus, and textboxes
- Rendering support that simplifies custom painting coding
While MainMenu, ToolBar, StatusBar, and ContextMenu are not included by default in the Visual Studio Toolbox, they are still included in the .NET Framework, primarily for backwards compatibility. Of course, the strip controls are located on the Toolbox so you can easily drag them onto your form. Through the Designer, you can add a variety of controls to each strip control (see Figure 10).
Figure 10 Controls Hosted by Strip Control
| Strip Control |
Designer-Allowed Strip Item Controls |
| MenuStrip |
ToolStripMenuItem (for both top menu and submenu items)
ToolStripComboBox
ToolStripTextBox
ToolStripSeparator (for submenus)
|
| ContextMenuStrip |
Same as MenuStrip |
| ToolStrip |
ToolStripButton
ToolStripComboBox
ToolStripSplitButton
ToolStripLabel
ToolStripSeparator
ToolStripDropDownButton
ToolStripTextBox
ToolStripProgressBar
|
| StatusStrip |
ToolStripStatusLabel
ToolStripProgressBar
ToolStripDropDownButton
ToolStripSplitButton
|
Strip controls offer a number of flexible configuration options. Both strip controls and strip item controls can be wholly configured from the Property Browser, while smart tags support configuration of the key properties for each specific control. If that's not enough, you can add, update, and delete strip items on the visual design surface directly, or from an Edit Items dialog, which can also be accessed from both Property Browser and smart tags, as appropriate.
Both MenuStrip and ToolStrip provide an Insert Standard Items option to prepopulate strip items for typical commands such as Open, Save, Save As, Cut, Copy, and Paste. Interesting configuration options you can apply are listed in Figure 11.
Figure 11 Key Strip Control Property Configurations
| Property |
Description |
| AllowItemReorder |
Users can reposition strip items by setting this property to True. The user needs to press Alt before repositioning (not for ContextMenuStrip). |
| ShowItemToolTips |
Sets whether strip items can also display tool tips (not for MenuStrip or Context MenuStrip). |
| Dock |
Specifies the form edge to line the strip control up against or fill. |
| RenderMode |
Strip controls support three render modes:
System: rendered with colors from the system palette.
Professional: rendered according to the current Windows Color Scheme—Blue, Olive Green, or Silver.
ManagerRenderMode: rendered using the Windows Theme sensitive ToolStripRenderer and is the default.
Custom is currently unsupported.
|
| SizingGrip |
Specifies whether the form sizing grip should be shown or hidden (StatusStrip only). |
| GripStyle |
Specifies whether a MenuStrip or ToolStrip displays a grip allowing it to be repositioned. |
| CanOverflow |
When the form becomes narrower than a strip control, this option specifies how to visually represent strip items that are hidden by the overlap, either hidden if False or accessible via a dropdown at the end of the strip control if True. |
Apart from standard properties you would typically find on controls, including Enabled, Visible, Checked, and BorderStyle, tool strip item controls also have several unique properties which are described in Figure 12.
Figure 12 Key Strip Item Control Property Configurations
| Property |
Description |
| DisplayStyle |
Specifies what to display; values include None, Text, Image, and ImageAndText. |
| TextImageRelation |
Sets the position of text in relation to an image. Applied when DisplayStyle is ImageAndText. |
| ImageScaling |
Specifies how an image is rendered, either ShrinkToFit or None. |
| Alignment |
Determines which end of a strip control a strip item control will align to, either Head or Tail (Left or Right sides, respectively, when rendering left-to-right). |
| Overflow |
Determines how each strip item control responds to overflow. Can be either Never, Always, or AsNeeded, which leaves the decision up to the host strip control. |
ToolStripContainer
Figure 13 Tool Strip
By default, strip controls sit where they lay at design time and run time. However, additional support for strip controls can be employed to enable developers and users to drag them from one form edge to another. If this is a feature you need to provide, you can use the new ToolStripContainer control. ToolStripContainer comprises four tool strip panels, shown in Figure 13 as blue, that surround a content panel, shown in gray.
The content panel is for the controls from which you'd normally compose your form. Tool strip panels are designed to house strip controls. The four buttons you can see on the edges of the tool strip panels expand and collapse the size of each tool strip panel by the height or width required for a single tool strip control. When you drag your strip controls onto the tool strip panels at design time, they are stacked horizontally or vertically next to one another. To change their position within the stacks, simply drag them to the new desired location. Z-Order is used to store and apply a strip control's stack position, with higher Z-Ordered strip controls residing closer to the form edge.
At run time, strip controls appear in their default tool strip panels when a form loads. Figure 14 illustrates how users can subsequently drag them from one form edge to another, as long as a ToolStripContainer was used.
Figure 14 Dragging a Strip
When a strip control is relocated to another tool strip panel, the tool strip container is shifted to make room. The benefit here is that all controls contained within the tool strip container are also shifted, saving you the trouble of doing the repositioning manually.
Strip Control Settings Management
Strip controls can have a lot happen to them at run time, with all the repositioning and strip item reordering going on. Since these are user changes, a good application should ensure that they are persisted across application sessions. Strip controls provide two properties that will make sure this happens automatically: SaveSettings and SettingsKey. SaveSettings is a Boolean that by default is set to False. When set to True by the developer, the strip controls persists values including raft position, location, size, and strip item control arrangement to the user settings subsystem that you saw earlier. SettingsKey is a String value that identifies the set of persisted values in the settings file:
FormName.StripControlName
You can change this as necessary, but once enabled, those values are automatically retrieved from user settings and applied to the strip control to make sure it is positioned correctly each time the application loads. Only strip controls and strip control items provide this feature currently, although you can add settings support in your own custom controls.
MaskedTextBox Control
Another new control, MaskedTextBox, is used for data entry. You use mask characters at design time to specify the type of data that can be entered and its format. For example, the mask character "9" specifies that a user can enter either a space or any number from 0 to 9, while the mask character "0" requires a number be entered. Of course, there is a wide range of mask characters, covering numbers, letters, punctuation, and spacing. Please refer to the evolving Visual Studio documentation for specific details. Developers can build a mask by setting the MaskedTextBox's Mask property with the appropriate mask value. The Input Mask editor, shown in Figure 15, lets you choose an existing common mask or construct your own, and it allows you to test them dynamically.
Figure 15 Input Mask Editor
Non-mask characters, such as parentheses, hyphens, and spaces, are treated as literals and are shown at run time to help build a stronger visual cue about the type of data that's being entered. On the other hand, all mask characters are replaced by a prompt character at run time (underscore by default), highlighting where the user should key in the data. At run time, the prompt characters are shown only when a MaskedTextBox has the focus.
MaskedTextBox implements a wide variety of properties (see Figure 16). It's a highly configurable control that you should utilize to give users a more informed data entry experience.
Figure 16 Key MaskedTextBox Properties
| Property |
Description |
| HidePromptOnLeave |
True by default but, if set to False, ensures that prompt characters are always visible. |
| PromptChar |
Used to change the prompt character. Underscore by default. |
| AllowPromptAsInput |
In some cases, your prompt character may also be a valid value and setting AllowPromptAsInput to True allows this when neither can be reasonably changed. |
| IncludeLiterals |
Specifies whether to include literal character values in MaskedTextBox's Text property. |
| IncludePrompts |
Specifies whether to include prompt character values in MaskedTextBox's Text property. |
| ResetOnPrompt |
If True, when a prompt is entered, a prompt is inserted and values on the right-hand side are shifted right. |
| ResetOnSpace |
If True, when a space is entered, a space is inserted and values on the right-hand side are shifted right. |
Data Binding
In our previous article, we looked at two new controls in the data binding space, GridView and DataContainer. Just as WinBar underwent substantial changes, so too have both data controls. GridView is now known as DataGridView, and DataContainer has been split into two new components, BindingSource and BindingNavigator. In fact, there have been many changes across the entire data binding subsystem; we'll explore the most notable of these changes.
Figure 17 Data Sources
A data binding needs a data source. You'll find it much easier to create in Visual Studio 2005. The simplest way is to select Data | Add New Data Source, which opens the Data Source Configuration Wizard. Your choice of data source has increased somewhat to include databases (as you'd expect), Web services, and other objects. If you were to create a data source from a database, not only would a new typed DataSet be added to your project, but you could also view it from the new Data Sources tool window (Tools | Data | Show Data Sources), shown in Figure 17.
The Data Sources tool window allows you to edit your data source with the typed DataSet designer, reconfigure the selected data source, refresh an existing data source, or add a new one. If you haven't already created a data source using these techniques, controls like DataGridView will prompt you to select or create an existing one when they are dropped on the form.
Binding to a Data Source
Just as there are several ways to create a data source, there are also several ways to bind controls to them. First, you can drag tables and fields from the Data Source tool window directly onto your forms. Behind the scenes, this simple act makes several important changes to your form, including:
- Adding a typed DataSet component to which your controls will bind
- •Adding a typed data adapter, if the datasource is a database, which assists with the loading and updating of your data
- •Adding a BindingSource component to expose the data source (discussed in the following text)
- •Adding a BindingNavigator component to the form for data browsing (discussed in the following