Windows Presentation Foundation is covered in some depth in Book V, but for now you should know that it is the future of Microsoft's Windows development experience. Book V talks all about WPF, so you can read more about it there.

The core of the user interface design experience is a language called XAML, which (unsurprisingly) is an XML-derived domain-specific markup language for the creation of user interfaces. In the Designer, shown in Figure 2-1, the design is in the top frame, and the underlying code is in the bottom frame.

You can click in the design in the designer and move things around, if you want, or use the designer to select things and edit the properties in the Properties panel (which I cover in the upcoming section "Paneling the Studio"). Additionally, if you change something in the code area, you'll see the change in the design. It's a good system.

There are a few small but significant features in the WPF designer that should be pointed out. You can see them all in Figure 2-1.

Near the upper-left corner is a zoom bar. You can click at the bottom of it and Zoom To Fit, or move the slider. This is invaluable for working on an application that is bigger than your screen, or lightening things just so.

At the left side of the dividing line between the Design and XAML frames is a little double-arrow icon. Clicking this icon changes whatever is in the bottom frame to be in the top frame, and vice versa.

Figure 2-1. The WPF Designer.

On the right side of the same dividing line are three buttons that determine the kind of split you have — a vertical split, a horizontal split (which is default), or no split.

A few cool point-and-click adjustment tools are in the designer itself. Here's just one: Click in the red area of the table in the window in the designer. Put your mouse right above where the "146" size designation appears.

See the little floating box that appears, with an asterisk, a hash, and the word Auto? That's just one of the many little helpers that you find in the WPF designer. The hash sets the column width to a set number (as it is by default). The asterisk sets it to a percentage of the table — useful for resizing. The word Auto sizes the column based on the contents.

These little features make changes only to the XAML in the frame below the designer. If you click the word Auto in the floating table designer, you will change this line of code:

<ColumnDefinition Width="146" />

to this line of code in the XAML frame:

<ColumnDefinition Width="Auto" />

Some people like the code. Some people like the designer. Some people (like me) prefer a strange mixture of the two. You determine how you want to use the tools.

The main difference between the Windows Forms designer and the WPF designer is the lack of a code panel in Windows Forms. Although there is code (of sorts) backing up Windows Forms, you don't get to edit it. So there.

The topic of Windows Forms isn't covered in this book. Though it's still an active development platform, I had to make the tough call to cover WPF instead. It performs the same programming duties as Windows Forms but is the newer technology. The Windows Forms designer is shown in Figure 2-2.

In truth, there is little to say about the Windows Forms designer itself. The individual controls have some nice designer features, but the designer itself doesn't do much.

It should be said, though, that I don't do much with Windows Forms in this book. First, this isn't a Windows programming book; it is a C# book. Second, Windows Forms is on its way out. WPF is the future of Windows programming. Window Forms is just there for backward compatibility.

Figure 2-2. The Windows Forms designer.

Web programming resembles WPF programming more than it resembles Windows Forms programming, but it's run from a Web server and viewed in a browser. ( Book VI is all about Web forms.) Because the designer has a back-end code element, you can see a split view, as shown in Figure 2-3.

Getting around in the HTML designer is easy. I want to point out two features in particular about the HTML designer. These features can be found in a menu strip along the bottom of the designer view:

Figure 2-3. Back to code with Web projects.

You can make a Class Designer from any project, but I used a Class Library project for my next example, shown in Figure 2-4:

Figure 2-4. My garden, in digital form.

The class designer gives you a visual interface into a class library. You can easily see the inheritance, and the members are visible and editable. Here is the class library I used for Figure 2-4:

namespace MyGarden
{
    public class Flower
    {
        public string Color;
    }
    public class Vegetable
    {
        public bool Yummy;
    }
    public class Daisy : Flower
    {
        public double Height;
    }
    public class Sunflower : Flower
    {
        public bool Harvested;
    }
    public class Tomato: Vegetable
    {

public double StakeHeight;
    }
    public class Carrot : Vegetable
    {
        public double Depth;
    }
}

To create a class library like this, follow these steps:

You can add methods to your new class as well. Click on the Methods of the Flower class and add a Water method by typing Water under name Void under type, and Public under modifier. If you change back to the library view, you'll find that there has been a method added to the code under that class.

Data View

Data View is usually used with the Server Explorer and is part of an in-studio representation of SQL Management Studio. You can view and edit data tables in the SQL Server (and other) database management system right inside Visual Studio. An example is shown in Figure 2-5.

There is a remarkable amount of power here, and there just isn't enough space to cover it all. Again, this isn't a database book, so I recommend reading over the MSDN entries for the Data Connections feature of SQL Explorer for more details.

Figure 2-5. When you use Data View, who needs SQL Management Studio?

Solution Explorer (see Figure 2-6) manages solutions, projects, and files. Despite my claim earlier that solutions are just a matter of files and folders, it is a somewhat more complex operation than it seems at first blush.

Figure 2-6. The explorer of solutions.

The Properties panel (see Figure 2-7) is a simple, flexible tool that allows you to update those endless lists of details about everything in development projects. The panel is basically a window with a two-column-wide datagrid. It reads properties in key/value pairs and allows for easy view and edit.

When I say it shows endless lists of details about everything, I mean everything. If you click on nearly anything in Visual Studio, press F4 to bring up the Property Panel (refer to Figure 2-7), you will get properties. Try it with these fun selections:

Figure 2-7. Paneling your property.

If there is any meta-data about something, the properties are in the Property Panel. It's a great tool.

One of the great misunderstood tools is the Toolbox. (See Figure 2-8.) On the surface it seems so simple. The design-time controls for a given file type are available to drag and drop. Still, there is one important thing you need to remember about the Toolbox. Wait, I'll get out my Remember icon.

So, if you are running a Windows Form in the designer, you won't see a database table available to drop. Trust me; if you expect to see a certain control, and it isn't there, the Toolbox probably isn't messed up. If there isn't a file open, the Toolbox is empty. That's by design.

I can't tell you how many times I have been expecting to see something in the Toolbox only to find it blank. Then I spend ten minutes tracking down the problem, only to realize that the problem is mine — I didn't have a file open. I once actually called Microsoft because I couldn't find a maskedtextbox for my Web Forms project.

Figure 2-8. The Toolbox, with tools.

There is no maskedtextbox for Web Forms projects.

So keep it in mind that the Toolbox is context-sensitive. It works only when it wants to.

There is one other interesting property of the Toolbox: It can be used to store text clippings, which can be useful for demonstrations and presentations. It is also handy for storing often-used pieces of code, but snippets (covered in Chapter 3) are even better. To do so, follow these steps:

Server Explorer enables developers to access important services on a remote machine. These could be anything from SharePoint to MSMQ but generally include two types of services:

Data connections

Above the Services in Figure 2-9 are the data connections. These are data connections that have been made on previous projects, which Visual Studio keeps around in case you need them for any other projects. Although keeping these connections around seems like a bit of a security risk, it sure as heck is convenient.

The goal is to reduce the dependency on SQL Management Console (the old method for managing the database for developers), and it does a darn good job. The key issue is access to the data model (table names and columns) and stored procedures; developing a program without access to the database is tough.

Figure 2-9. Server Explorer.

In a new connection, these database objects are given default folders:

• Database diagrams

• Tables

• Views

• Stored Procedures

• Functions

• Types

• Synonyms

• Assemblies

The key thing I want you to try is opening a Stored Procedure (you can do this by double-clicking it in the Data Sources panel). When you do so, you can easily edit SQL code, with indenting and colorization, right in Visual Studio. Use this. It's really neat.

The last of the five main panels is Class View. As I discuss throughout Books I and II, everything in the .NET Framework is an object. The classes that make up the framework — all derivatives of Object — are viewable in a tree view.

The Class Viewer is the home for that tree view. (See Figure 2-10.)

Figure 2-10. A viewer with Class.

From the Class View, you can look at all the members of a class and access the inline documentation, which gives you an overview of the framework and custom classes that make up your project.

The Code Viewer is where you edit code. Doesn't matter what type of code, all of it is edited here. (See Figure 2-11.)

Figure 2-11. Viewing the Code Viewer.

It is a smart tool, however. If you are in XML, it works like an XML editor. In C++, it helps with the tabbing.

You can get to a code file in the Code Viewer a few ways. The most common way is to double-click on a code-driven file in Solution Explorer, and it will open in Code Viewer.

If you are viewing something in the designer, you can get to the code-behind related to the file in question by any of three methods:

You'll find yourself using all three over time. Note that you can get directly to the code-behind files by clicking the little triangle next to a designer file and then double-clicking the code files nested within.

Outlining

Visual Studio will auto-outline your code for you. Notice the little box with a minus sign (−) next to every namespace, class, and method? (See Figure 2-12.) Those are close-up sections of the code for readability. Doesn't seem like much now, but when you have 2,200 lines of code in there, you will be glad.

Figure 2-12. Teeny little outline marks.

You can create your own outlining, too. Preceding a section that you want to outline, put #region on a new line. After that section, put #endregion. This newly defined section — regardless of whether it's at an existing outline point — will get a new outline mark.

If there is a comment added after a region statement, it will show in the collapsed outline — as you can see in Figure 2-12.

A number of windows affect text input and output in order to solve certain problems. As a group, they don't really have a name, so I call them auxiliary windows. I cover four of them here.

I am sure you are shocked to find that the Tools menu is a great place to find tools that don't fit anywhere else, including the following:

I'm sure by now you have gotten the basics of building and debugging. A few other options in the Build and Debug menus deserve at least a small explanation, including the following:

Refactoring is the practice of reorganizing code that might have become scattered during development or debugging. The Refactoring menu in Visual Studio provides a few tools that help with refactoring in C#, including these: