Catálogo de publicaciones - libros

Derived controls provide an ideal way to take functionality from the existing .NET control classes and extend it. A derived control can be dramatically different from its predecessor, or it may just add a few refinements. Sometimes, derived controls are used to fasten a new feature onto an existing control (for example, you could create a TreeView that supports data binding). In other cases, derived controls customize more-general controls to work with specific types of data (like the Directory tree in this chapter). The only common thread is that all derived controls aim to avoid the heavy lifting by borrowing the features of another class.

In Chapter 7 you learned how to use GDI+ to draw text and complex shapes on a form by overriding the OnPaint() method. Although this technique works perfectly well, most of the time you’ll want to build an application out of smaller controls that paint themselves individually. Taken to its logical extreme, you can use this technique to build hand-tooled interfaces with the latest in eye-catching graphics (something you’ll consider again in Chapter 23).

The custom controls you have explored so far are full of promise. Being able to drop a tool-like directory browser or thumbnail viewer directly into your application without writing a line of extra code is a remarkable advantage.

.NET 2.0 does something that’s more than a little surprising with its toolbar, status bar, and menu controls—it tosses out the .NET 1.x standbys and replaces them with an entirely new model. The old controls like the ToolBar, StatusBar, and MainMenu are still available (rightclick the toolbox and select Choose Items to hunt for them), but they’re intended only for backward compatibility. Now, a new set of classes that includes System.Windows.Forms.ToolStrip and two other derived classes (MenuStrip and StatusStrip) provides a completely new model for toolbars and menus.

The first two releases of the .NET Framework (.NET 1.0 and .NET 1.1) left a glaring gap in the data-binding picture. Although developers had a flexible, configurable model for linking almost any control to almost any data source, they didn’t have a practical way to display full tables of information. The only tool included for this purpose was the DataGrid control, which worked well for simple demonstrations but was woefully inadequate for real-world code. Most developers found that the DataGrid was awkward to use, inflexible, and almost impossible to customize. Oddly enough, the DataGrid lagged far behind its ASP.NET counterpart, making it more difficult to display rich data-bound tables in a Windows application than in a web page.

Great user interfaces don’t stop at buttons and text boxes. They include multimedia features like soundtracks and even live video. One of the most glaring omissions in the first versions of .NET was the lack of any controls for dealing with audio. This gap forced developers to dig into the Windows API just to play simple sounds and beeps. Fortunately, .NET 2.0 addresses this problem with a new SoundPlayer control that lets you play WAV files synchronously or in the background.

The WebBrowser control is another new frill in .NET 2.0. Essentially, the WebBrowser allows you to embed a full-featured Internet Explorer inside any window. This feat was technically possible in previous versions of .NET using interop and the Internet Explorer ActiveX control. However, the interop approach suffered from a few annoying quirks that the WebBrowser control deftly avoids. The WebBrowser control also adds a remarkable piece of new functionality: the ability to interact with the contents of a Web page programmatically using a specially crafted (DOM). In other words, you can access individual HTML elements on a Web page, tweaking their text, changing their position, or inserting new markup. You can even handle JavaScript events that originate from a Web page in your form code. If you’re willing to invest a fair bit of work, you could use these features to build something really unique, like a next-generation help engine, a screen-scraping Web browser, or a blended interface that incorporates both Windows and Web controls.

In any realistic application, you need to have some sort of error-checking hard-wired into the user-interface code. If you don’t code this logic properly or if you put it in the wrong place, you may frustrate users, complicate the business process, and even lose data.

As long as developers have had graphical windows to play with, there have been heated debates about the best ways to organize these windows into applications. Although there are hundreds of possibilities, most user interfaces tend to fall into one of three categories:

One of the great advantages of rich client applications is their support for —in other words, their ability to perform multiple tasks at the same time and still remain responsive. The same feat isn’t possible in a typical server-side Web application. Although Web browsers are themselves multithreaded pieces of software, most Web applications strictly separate the work that’s done in the browser from the work that’s done on the server, for both security and compatibility reasons. As a result, there’s little (if any) support for background processing. Even if the server-side application uses multiple threads, the user is still stuck waiting until all the work is completed before the final HTML for the page is rendered, sent back, and displayed in the browser.