Flylib.com

Books Software

 
 
 

Basic Control Debugging


Basic Control Debugging

By now you may be wondering how to debug controls, designers, and editors. As with any class library project, there needs to be an application that will use the library. This application can be set as the startup program for debugging purposes. In the case of designers and editors, VS .NET provides the solution. In the project properties, set the Start Application to devenv.exe , as shown in Figure 5.9.

Figure 5.9. Debugging setup.

figure 5.9. debugging setup.

Now when the project is executed, a new instance of VS .NET will be launched. This will allow for setting break points within the control, designer, and editor.


Summary

This chapter certainly covered a lot of ground and provides a point of reference for the entire book. With the designer architecture and services detailed in this chapter, you have all the basic information you'll need in order to create advanced controls. I suggest reviewing the various base classes and interfaces presented here before moving on to the remainder of the chapters.

The next four chapters are dedicated to building a fairly complex control, along with designers and custom editors. Many of the designer services, classes, interfaces, and attributes listed in this chapter will be used during the construction of the OutlookBar, aka the Shortcut Control.


Chapter 6 - Control Design Concepts

IN THIS CHAPTER

  • Control Design

  • Control Internals

  • A Preview of the OutlookBar Control

Building quality custom controls requires knowledge and practice. During the development process, there is a time of discovery. This discovery process includes learning the underlying system, the framework, and the most practical design for the control in order to provide a clear strategy for moving the project forward. To grow knowledge, there must be a starting point from which to begin. The Windows Forms base class library can be used as such a starting point.

By studying the current set of controls and their associated designers and UITypeEditor s (see Chapter 5, "Advanced Control Development," for more information on UITypeEditor s), you can glean lessons and apply them to new endeavors.

Before this chapter delves into designing and building the OutlookBar control, its subcomponents, and related designers, a tour of the existing set of Windows Forms controls will provide some insight that can be applied to the construction of the OutlookBar control to be built in chapters 7, 8 and 9.

It is necessary to understand how the common controls shipped with VS .NET are constructed so that the principles behind their design and implementation can be applied to new custom controls. The remainder of this chapter is spent exploring the concepts behind the implementation of the current common controls. In addition, we explore how to use the current set of controls to gain a better understanding of how to create custom controls.


Control Design

All Windows -based applications provide several well-known UI elements, such as menus , toolbars, and status bars. Beyond these basic UI elements, most modern applications provide their own custom set of controls and/or extend common UI elements to add some flair to the application. The leader and most-often-imitated UI elements are Microsoft's. MS Office has been a constant source of new UI elements and ideas for third-party control vendors . Advanced docking toolbars , custom menus, and windows are now available from several different vendors.

Users of Visual C++ and MFC (Microsoft Foundation Classes) have some basic UI elements afforded to them, such as simple docking toolbars. However, advanced UI elements such as those found in the latest edition of MS Office and VS .NET are not to be found within any provided framework or .NET classes. If you want your application to resemble a Microsoft application, you will have to purchase a set of libraries from a third-party vendor or create your own set of UI classes.

As with any type of project, certain criteria should be followed when creating custom UI elements. These are the criteria:

  • Looks cool

  • Looks really cool

  • Concise usage

  • Design-time support

Did I mention that it needs to look cool? After all, if you want your control to be noticed, it has to have a sexy wrapper. Consider the menus in VS .NET verses the standard menus available as part of Windows Forms development. Figure 6.1 shows a side-by-side comparison of these two menus.

Figure 6.1. A menu comparison—VS .NET on the left, boring on the right.

figure 6.1. a menu comparison—vs .net on the left, boring on the right.

Both menus shown in Figure 6.1 provide the same functionality; however, users looking at the two will believe that somehow, in some way, the cooler -looking menus translate into a more powerful application. When building a control, make sure that it (a) looks cool and (b) looks really cool.

Of course, if the control only looks cool but does not offer any functionality, it is useless. Creating a nice-looking control will get a developer's attention, and providing a useful control will get developers to actually use the control.