In-Depth
WinForms Gain Ground in Whidbey
New controls, enhanced data binding, and improvements to existing controls make WinForms programming with VS.NET's upcoming version easier and more versatile.
Technology Toolbox: VB.NET
The alpha bits available now for the Whidbey version of VS.NET offer an opportunity to dive into upcoming WinForms changes. Developing smart client applications with Whidbey will be easier and more efficient, thanks to new design-time widgets, improved data binding, enhancements to existing controls, better deployment, and new grid, toolbar, splitter, and sound controls. The alpha bits are a technology preview—not a beta—so the feature list isn't closed; some features might disappear, and new ones might appear. I'll focus on enhancements and new features, but bear in mind that Whidbey is one step in a long series of WinForms improvements, and it's not realistic to expect it to solve all the platform's issues. For example, GDI+ is still difficult to use for simple drawings, and many controls have hardly evolved since Windows 3.1. The entire Windows interface experience is due for a major update in 2005 (see the sidebar, "Avalon Emerges From Longhorn's Mists").
Whidbey solves some outstanding problems with existing controls. For example, the ComboBox finally supports the BorderStyle and FlatStyle properties for a modern appearance, along with a DropDownClosed event. Scrollable controls, such as panels, have a Scroll event, and it looks like you'll be able to scroll individual controls' contents programmatically. You can change button borders' color and size and use double buffering to avoid flickering while you're rendering graphics. You can retrieve the character at a specific position, or the position from the character index, from the RichTextBox and controls that inherit from TextBoxBase (ComboBox and TextBox, for example). These small enhancements combine to make it easier to develop sophisticated smart-client applications.
You might have seen or heard about demos of automatic data-form creation with Whidbey that enables you to build forms in two or three minutes. This feature is impressive, but I'm waiting for the forms' final look and feel to determine how useful they'll be. However, it's clear already that the control they're based on—the DataContainer—is extremely useful. The DataContainer is a container, derived from Windows.Forms.Panel, that manages a DataSource, including your current position (or cursor) within the DataSource. The DataContainer can have three distinct personalities. You can use it as an abstract DataSource manager, much like the CurrencyManager of .NET 1.0 and 1.1. As a container, it provides default binding for controls you drop onto it. It can also provide a VCR-like experience for your end users, much like the DataControl of VB6 and previous versions. The DataContainer is relatively lightweight, unlike the VB6 DataControl.
Display Data Without Coding
Whidbey's new data features—such as support for multiple tab pages—let you push forms to higher, real-world complexity. A single-page form with a splitter lets you visualize how Whidbey manages a higher level of sophistication (see Figure 1). The DataContainer contains the entire splitter. The grid in the left panel within the splitter displays customers the user can select from to view additional data. The right panel contains details on each customer and a second grid displaying orders for each customer. This data layout requires no code, because the DataContainer does all the work. The only code responds to toolbar events (which I'll discuss later) that drive the DataContainer behavior from the outside. You simply drag the Customer table from the SQL Server Northwind database onto the DataContainer to configure the DataContainer in this example.
Putting the splitter within the DataContainer isn't necessary. The data-binding behavior would work the same way if you placed the DataContainer on the form independently, but placing controls in the DataContainer provides more logical VCR positioning and default data binding for controls you drop on the form. You provide Figure 1's layout by docking the DataContainer to full, then dropping the new SplitContainer and docking it within the DataContainer. (Docking appears unchanged from earlier versions of .NET.) The new SplitContainer consists of two panels and a visual splitter. It looks like a splitter at design time, and you don't need to worry about ZOrder—a significant step forward.
The grid in each panel is the new GridView. The GridView largely replaces the DataGrid. (The DataGrid remains in Whidbey for backward compatibility, and because it's the only hierarchical grid Microsoft offers.) The GridView works as either a bound or unbound grid. VS.NET sets the DataSource to the DataContainer if you drop the GridView onto a previously configured DataContainer. The form in Figure 1 reflects a few additional changes, including turning off the "Autogenerate Columns" feature, removing extra columns from the left grid, turning off row headers, and docking the grid.
A SmartTag appears at the DataContainer's lower right. It offers options to create a Detail or GridView of your data and lets you switch between these views. VS.NET puts a set of label and text controls on the form when you click on the Detail view. VS.NET adds these same controls when you build the wizard-based data forms Microsoft has been demonstrating. It then gives them meaningful names—such as txtCompanyName, instead of TextBox4—and you can use SmartTags to change from a TextBox to another control, such as a ComboBox.
VS.NET can't know which panel of the splitter control you want the new controls in, so it simply drops them onto the DataContainer. You can cut and paste them into the proper panel. You lose the DataMember for each TextBox when you do this (this might be an alpha bug), so you must reset them. Resetting them demonstrates another way to data-bind controls—dragging fields from the DataSource Field Explorer. You can also resize and anchor them, as in the example.
Whidbey Recognizes Relations
Dragging another GridView onto the right panel defaults the grid to display the customer data, as before. This isn't what you want, so change the DataMember to use the DataSource's foreign key relation—FK_Order_Customer. This is pretty nifty, because you never added the relation to the .NET side. It existed in SQL Server, and Whidbey recognizes relations (at least for SQL Server) automatically when you drag and drop data elements.
Once you remove the row header and dock the Orders grid at the bottom of the right panel, you're done with the form's data portions and can test the form. As you move the position in the left grid from one customer to another, the right panel displays data for the current customer, including both the detail and the list of orders. All this behavior is part of the DataContainer; you haven't written a single line of code yet.
I'm not wild about the DataContainer's VCR control, mostly because its position is at the bottom of the DataContainer. You can implement similar features in a WinBar if you want to put all user actions in a single toolbar (see Listing 1). Microsoft redesigned the toolbar—like the DataContainer—between .NET 1.1 and Whidbey. The changes broke backward compatibility, so Microsoft created the new WinBar control. Microsoft is deeply committed to maintaining backward compatibility with previous versions of the .NET languages—that is, enabling your .NET 1.0 and 1.1 code to run in Whidbey and beyond. Creating new controls lets Microsoft maintain forward momentum while letting you incorporate new features into your organization's development schedule with a minimum of disruption. The form in Figure 1 includes the original VCR controls so you can see how they look with XP styles enabled. You can turn the DataContainer's VCR control on or off by setting a Boolean property in the property dialog.
Listing 1 shows how straightforward it is to implement the VCR control's basic features through your own code. The first six buttons reposition the DataContainer's cursor. Repositioning the DataContainer repositions the customer grid and all the associated controls. The Page Up and Page Down buttons move the DataContainer by the number of rows currently displayed in the grdCustomers GridView. The PositionChanged event lets you update the row position the toolbar displays when the DataContainer's position changes for any reason. (Listing 1 puts this in both the WinBar and DataContainer so you can compare their appearance in Figure 1.) The position within the DataContainer is zero-based, so you must add 1 to give the user a friendly one-based display. The DataContainer exposes its CurrencyManager, which you can access for properties such as the Count of data rows. The New, Delete, Undo Edit, and Load buttons call the corresponding DataContainer methods. Microsoft might add simple properties, such as Count, to the DataContainer so you don't need to access the CurrencyManager as often.
Figure 1 illustrates the XP visual styles. XP visual styles were available in VS.NET 1.1 but had several problems Whidbey appears to have fixed. You enable the XP look and feel by adding a line of code to a Sub Main or the startup form:
Application.EnableVisualStyles()
Listing 1 contains the preceding line in the form's Load event.
Access Internal Controls
The WinBar control contains some controls that derive directly from WinBarItem, such as the WinBarButton. Others, such as WinBarComboBox and WinBarTextBox, derive from WinBarControlHost, which derives from WinBarItem. WinBarControlHost controls host—or contain—another control, which itself provides the UI behavior. Understanding this design is important when you want to alter the contained control's behavior. For example, the TextBox and ComboBox in Whidbey have great new autocomplete features. You can access the user's URL history list, as well as file and "recently used" lists that Windows maintains on the user's computer already (see Figure 2). You can even create custom lists. For example, you can maintain a list of accounts a user has accessed recently within a search dialog. However, you must access the internal control to use these features from the WinBarTextBox or WinBarComboBox (see Listing 2).
Figure 2 also illustrates the WebBrowser control (see Listing 2). This control wraps the ActiveX control you might have used in .NET 1.0 or 1.1. It provides the most commonly used functionality through managed code to make working with the control easier. WebBrowser allows you to navigate to various URLs and to display HTML documents. It offers numerous options for controlling the way your users navigate the Web.
Listing 2 includes the control declarations so you can see the specific controls the form in Figure 2 uses. The txtURL variable is set to the TextBox contained within the WinBarTextBox in the form's Load event. The code uses the txtURL variable to attach an event handler for this control's KeyUp event. It also specifies the autocomplete features of the txtURL TextBox in the Load event. You can't access the contained TextBox's properties through the Properties dialog in this Whidbey build.
You provide standard behavior for the WebBrowser control by attaching the event handler to the KeyUp event. The WebBrowser control opens the page when the user selects an item and presses Return. The KeyUp event checks which key the user pressed. If the user pressed the Return key, the method shifts the focus and calls the Go method to display the URL. You must shift the focus to fold up autocomplete's dropdown. The Go button calls the Go method, which calls the Navigate method of the WebBrowser with the contents of the WebBarTextBox. The final piece of the form is the ProgressBar. The WebBrowser control raises an event that lets you give your user feedback on the load process. The form in Figure 2 uses another little trick: The panel with the ProgressBar is contained in a FlowControl panel set to RightToLeft, which lets you flow the controls from right to left.
You'll see many more features in the coming months as the Whidbey feature set stabilizes. The solutions it provides so far seem well thought out. Along with the new controls and the new methods and properties for existing controls, Whidbey offers significant design-time improvements and enhanced click-once deployment. Whidbey is a great step forward for WinForms programmers and should help bring Windows programming back into the mainstream for appropriate applications.