Chapter 1 - Windows Controls

function OpenWin(url, w, h) { if(!w) w = 400; if(!h) h = 300; window.open(url, "_new", "width=" + w + ",height=" + h + ",menubar=no,toobar=no,scrollbars=yes", true); }

IN THIS CHAPTER

• Control Concepts

• Control Anatomy 101

• Control Appearance and Behavior

• Composite Controls

• VS .NET Integrated Development Environment (IDE)

One of the early premises of the Windows operating system was to define a common set of user interface elements to be shared by all applications. The idea was that a user could learn one application and apply that knowledge to other applications. Each application shared common user interface elements such as menus, toolbars, and dialog boxes, thereby creating a sense of unity between all Windows-based applications.

Over the years, the Windows common controls set has been expanded to include more and more user interface elements that have become commonplace in applications. Of course, these common controls stem from the Windows operating system itself and the advances of its own user interface.

The development of the Windows UI (User Interface) controls has not been limited to just advances in the Microsoft Windows environment; rather, many third-party companies have built their entire livelihood off of creating custom controls for Windows developers. Often, these custom controls mimic the various UI elements found within the latest Microsoft products, such as Visual Studio and the popular Microsoft Office line of products.

The reason for the thriving market is customer driven. Customers expect that applications have the latest UI elements found in typical Microsoft products. Somehow a slick up-to-date UI translates to a more powerful application. This assumption is not always accurate, but a modern UI goes a long way in selling software just ask any commercial software developer.

I have often been asked, "Why doesn't Microsoft release its UI components for use by other developers?" Well, the answer is not very straightforward. Each development team at Microsoft typically creates its own UI controls, and devoting a single group to creating UI components is not cost-efficient or profitable for a company the size of Microsoft. A top Toolkit company, as custom control development companies are called, can expect to see revenues of $5 to $7 million annually. For Microsoft, this would probably cover the landscaping for the main campus.

Developing custom controls is a rewarding experience that allows for a deeper understanding of Windows development and the development environment, such as Visual Studio. Gaining a solid understanding of the Windows subsystem, GDI+ (Graphics Device Interface+), and user interaction, such as a mouse and keyboard, tends to push custom control developers to create more powerful and feature-packed controls and applications.

The remainder of this chapter discusses basic control concepts such as runtime verses design-time support. In addition, the basic anatomy of controls is covered.