Maarten Struys
PTS Software bv
OpenNETCF.org

November 2005

Applies to:
Microsoft Visual Studio 2005
Microsoft .NET Compact Framework version 2.0
Windows Mobile version 5.0
Windows Mobile–based Pocket PCs
Microsoft Windows CE

Summary: Learn about what''s new in Visual Studio 2005 for user interface and database design to use for .NET Compact Framework version 2.0 applications. This article introduces you to the new development environment—specifically to the new Windows Forms Designer that is part of Visual Studio 2005. You will also get a short guided tour of the new controls that are available out of the box in Visual Studio 2005, and you will learn how easy it is to create applications that support both portrait and landscape modes using these controls. Visual Studio 2005 helps you target multiple devices. You will also learn how you can use form inheritance to reuse and extend existing forms. Because most mobile line-of-business applications also need to store and access data, you will also learn how to use the new data designer in Visual Studio 2005 to create and populate a SQL Server 2005 Mobile Edition database. Also in this article, you will find out how to create a local database and how to use it in a simple application. (36 printed pages)

Download Using_VS2005_to_Design_User_Interfaces_and_Databases_for_Device_Applications.msi from the Microsoft Download Center.

Introduction

With each new version of Visual Studio, developer productivity increases because the visual designer tools become richer and more code is generated for developers. This code has a big advantage because you don''t have to concentrate on writing all kinds of plumbing code; instead, you can concentrate almost entirely on the functionality that is needed for your application. Because there are many devices out in the market, all with different form factors, it is crucial to have true what-you-see-is-what-you-get (WYSIWYG) user interface design tools that match the final user interface as close as possible. As more and more applications are required to locally store significant amounts of data on devices, the ability to visually design tables and databases for SQL Server Mobile databases inside your development environments will help you. Visual Studio 2005 offers you great design tools that ease a lot of work that is involved in user interfaces and data design.

By reading this article, you will find out how you can create user interfaces that can dynamically change between portrait and landscape modes without having to write one line statement of code yourself. When you are creating an application that uses multiple forms, each with a number of common characteristics, you can use form inheritance with complete designer support to limit the amount of code that you have to provide for each individual form. Finally, when you are using a local database inside your application, you can create the database and even populate it by using Visual Studio 2005 designer tools.

Designing a Simple User Interface for Windows Mobile 5.0-based Pocket PC

To start developing a new device application, you first need to create a new project in Visual Studio 2005. The project should be a Smart Device project in either C# or Visual Basic .NET that targets a Pocket PC that runs Windows Mobile version 5.0. Although not relevant for the Windows Forms Designer itself, all code samples are presented in C# throughout this article. However, all code samples are also available in Visual Basic .NET for download.

When you are creating a new device application, Visual Studio 2005 shows you an empty form with the correct dimensions for the target device—including a device skin to match a real device as close as possible. By using the Device Controls Toolbox that is displayed in Figure 1, you can drag controls to the application''s form.


Figure 1. Visual Studio 2005 Designer view

If you compare the number of device controls in the Toolbox to the number of device controls in Microsoft Visual Studio .NET 2003, you will see that there are many more controls available in Visual Studio 2005. If you are not familiar with the new controls, the best thing you can do is create a simple application by using the new controls, look at each control''s properties, and study their behaviors. You should, of course, also look at the online help for the particular control. When you start designing your user interface, something that immediately gets your attention is how the Windows Forms Designer helps you align controls and suggests a minimum distance between controls. The automatic display of guide lines, as shown in Figure 2, help you tremendously in creating a well-organized user interface in a short amount of time.


Figure 2. Guide lines help you lay out your user interface

Docking and Anchoring Controls

To make sure that a form is displayed correctly in both portrait and landscape mode, it is possible to dock and anchor controls to a specified location inside a container. There is a subtle, yet important difference between docking and anchoring. When you anchor a control to one or more edges of a container, you make sure that the relative position to the anchored edges are maintained when the display orientation of the device is changed. When you dock a control, you specify the edge of the container against which the control will be positioned. You can even specify that a control should be docked to all edges, meaning that the control will fill the entire real estate of the container. A container is the host of a control, or in other words the parent of a control. For instance, a container can be the entire form, but it can also be a GroupBox or a Panel.

To show the difference between anchoring and docking and to show the behavior of anchored and docked controls in different display orientations, you can create a simple user interface that contains a number of Label controls—each with different background colors—and then you can simply look at the behavior of anchoring, docking, and orientation changes. The user interface design is not particularly meaningful, but it will help you understand the difference between docking and anchoring. It will also show the impact on changing from portrait mode to landscape mode. Suppose you have created a user interface that looks like Figure 3.

Figure 3. Pocket PC in portrait mode with a user interface that has labels and a panel that are neither docked nor anchored

The three upper labels are hosted on a panel; the two lower labels are hosted on the form itself. For all controls that you add on the form, make sure to explicitly remove anchoring. The default behavior of Visual Studio 2005 is to anchor all controls to the top and left edges or their hosting containers. The user interface looks fine in portrait mode, but when you change the orientation to landscape mode, you will run into problems, as shown in Figure 4.

Figure 4. Pocket PC in landscape mode with a user interface that has controls that are not docked or anchored

You can immediately see that not all of the labels that showed up in portrait mode are visible in landscape mode. Part of the panel, including label1, is off of the screen. Also label5 has disappeared from the screen, and the right and left sides of the display are not filled in in landscape mode. It looks like landscape mode merely views part of the portrait mode''s user interface.

To solve this problem, without having to write actual code, you can make use of docking and anchoring, which is new for .NET Compact Framework 2.0 applications. You can simply anchor a control to one or more edges of the screen by setting the Anchor property. Anchoring a control means that the relative position to the anchored edge always remains the same—independent of display orientation. By using the Dock property, you can specify how a particular control aligns to an edge of its parent control or fills up an area of the screen. Docking multiple controls to the same edge of their parent control causes the controls to stack upon the other. If you look at Figure 5, you will see there are few differences from Figure 3. However, this time the controls are anchored and docked.


Figure 5. Pocket PC in portrait mode with a user interface that has docked and anchored controls

In Figure 5, the labels describe how they are docked. The three upper labels are all owned by a panel control. The topmost label is not docked, but it is anchored to the left, top, and right edges of the panel control, which in turn is docked to the top of the form. Independent of the display orientation, the distance between the left, top, and right edges and the label will be the same. The label will be resized when the user interface is displayed in landscape mode. The other two labels inside the panel control are displayed on top of each other; both are docked to the bottom of the panel control. The tab order determines the way in which these labels are displayed. If you now change the display''s orientation to landscape mode, all of the controls on the form will remain visible, and the entire size of the form is used to fill up the controls, as shown in Figure 6.

Figure 6. Pocket PC in landscape mode with a user interface that has docked and anchored controls

The user interface shown in Figure 6 looks much better than the one that is shown in Figure 4 because the individual controls have resized to properly display in landscape. To really get a feeling about how docking and anchoring influence the position of controls in both portrait and landscape mode, you should spent some time experimenting with it.

In Visual Studio 2005, it is very easy to view your user interface in both orientation modes—even in Designer view. To change the orientation of the device in Designer view, simply select the entire form (by right-clicking anywhere on the form where no controls are placed, by right-clicking the form''s title bar or by right-clicking on the device skin, and then selecting Select <form class name>) in the shortcut menu. If you have only one single form in an application and if you use the default name that Visual Studio 2005 assigns to that form, <form class name> will be Form1. When you have selected the entire form, the shortcut menu that is displayed if you right-click the device skin contains different entries, including Rotate Left and Rotate Right. You can use these to change the orientation of the display, as shown in Figure 7. Alternatively, after selecting the entire form, you can use toolbar buttons to change the orientation

Figure 7. Changing display orientation in Designer view

Splitter Control

One of the new controls that is available with the .NET Compact Framework 2.0 is not entirely self explanatory and is not obvious to use. You can use the new Splitter control in combination with docked controls to change the size of those controls during runtime, similar to the Splitter control in the full .NET Framework.

During design time, you can simply add Splitter controls, and you have the possibility to set their sizes. The order into which you add docked controls and Splitter controls to the form determines on which docked controls a splitter operates and also determines the way the Splitter control is shown to the user. According to the Visual Studio online help, the Splitter control enables you to resize the docked control that is immediately before it in the docking order. Because there is no way of manually setting the docking order, you have to add a Splitter control immediately after adding the docked control you want to resize. You also need to make sure to dock the Splitter control to the edge of the docked control that you want to resize, as shown in Figure 8.


Figure 8. Splitter controls in Designer view

The user interface in Figure 8 is created in the following way. All three picture boxes are added to the form one after the other and docked to the top and the right of the form; the last picture box, showed on the lower left part of the form in Figure 8 is docked to fill. After creating the picture boxes, two splitters are dropped on the lower left picture box and docked respectively to the top and the right of that picture box.

Looking to the user interface in Designer view, you might think that the picture box on the right side of the form can be resized in a horizontal direction only, and the picture box on the left side can be resized both in horizontal and vertical directions. However, as you can see in Figure 9, when you move the horizontal splitter, all of the controls will be modified according to the location of the splitter. This behavior is caused by the fact that the lower right picture box is docked to the right edge of the form—always trying to occupy as much space as is available on the right edge of form. This example shows that controls that are not immediately associated with a splitter can still affect their sizes. Although this example is useful for demonstrating the relationship between splitter bars and docked controls, it is not recommended to create a user interface with such complex behavior.

Figure 9. Resizing docked controls by using Splitter controls

To give users a better visual indication about how the Splitter controls are affecting docked controls, you should consider the order into which you dock controls. You must add a Splitter control that is supposed to work on a docked control before adding other controls with common docking areas, as shown in Figure 10.

Figure 10. Splitter controls in Designer view that were created immediately after the docked controls that need resizing

When you create the same user interface in a different order, you can see the difference. The horizontal Splitter control is created immediately after the top picture box was created. Then, the right picture box was created, which was followed by the vertical Splitter control, and, finally, the last picture box was created. Even though the resizing behavior during runtime has not changed, the order in which the picture boxes and splitters were created has changed, which gives users a much better idea about how the splitters will resize the different controls, as shown in Figure 11.

Figure 11. Resizing docked controls by using Splitter controls that were created in the correct order

Setting the Tab Order

To determine which control gets focus, in other words which control can accept keyboard input, the tab order is used. It is called tab order because you can change focus from control to control by using the TAB key on the keyboard (even on a soft input panel that is available on Pocket PCs).

In Visual Studio .NET 2003, the tab order for those controls that can accept keyboard input was more or less fixed. The tab order reflected the order in which controls were created during design time and could not be changed without deleting and re-adding the controls in a different order. In Visual Studio 2005, it is possible to change the tab order after you create all of the controls for your user interface, which gives you more flexibility because you don''t have to think about the tab order while designing the user interface. For example, look at Figure 12, which is a project in Designer View with the original tab order.

Figure 12. Original tab order

The project has a very simple user interface that is only used for demonstration purposes. The controls on the form were created in a particular order. The button was created first, which was followed by the DateTime control, and, finally, the two text boxes were created. The order in which the controls were created determines the initial tab order. By clicking the Tab Order button on the Layout toolbar, which is circled in Figure 12, you can view and modify the tab order.

If you leave the tab order for this particular application as is, you will see that navigating through the controls when running the application is not the best experience. Initially, the input focus is set to the button on the user interface. Pressing the TAB key changes the input focus to the DateTime control. Pressing the TAB key again changes it to tBox1 and finally to tBox2. It would be more natural to a user to navigate to all controls from top to bottom. In Visual Studio .NET 2003, allowing a user to navigate from the top of the user interface to the bottom could only be achieved by creating the controls in the order in which you want a user to navigate through them.

In Visual Studio 2005, when the Tab Order button on the Layout toolbar is selected, you can simply click each control that has the ability to receive input focus to change its tab order. This implies that you simply add controls to a form without having to think about the tab order because you can modify the tab order at a later time, as you can see in Figure 13.

Figure 13. Modified tab order in Designer view

When you run the application now, you can see that navigating through the controls is more natural because input focus changes from each control starting at the top of the user interface and working down. It is also possible to set the tab order for individual controls by using the TabIndex property. You can also specify if a user can navigate to a control by tabbing through a form by setting the TabStop property. These properties are implemented only for those controls that can accept keyboard input.

Changing Device Form Factors

The original Pocket PC had a screen resolution of 240 x 320 pixels. A number of Pocket PCs available today have different screen resolutions or even square screens. To make sure that your application looks good on all of these devices, you can set the FormFactor property. The FormFactor property is a design-time value only. In other words, it does not influence your application itself. You can use the FormFactor property to set a number of different screen dimensions for a device, so you can verify that your user interface is shown properly on devices with different form factors during design time. As you can see, Figure 14 shows a simple text editor that runs on a Pocket PC. If you look at the download code sample, you can appreciate the rich functionality that is available to you when writing managed code by using the .NET Compact Framework 2.0. The entire functionality of this sample editor takes about 30 lines of source code, including the possibility to open existing files and save files. Of course, this sample is very limited in functionality and does not provide any spelling or grammatical checking or typical editorial functionality such as find and replace, but the sample is fully functional.

Figure 14. A Pocket PC application with a user interface for a simple text editor

Suppose that you want to run this application on a Pocket PC with square screen dimensions. Thanks to anchor controls, it is very easy to keep the same user interface without having to write any code. The new design-time only property, FormFactor, allows you to verify the appearance of the application within the Visual Studio 2005 designer. As you can see in Figure 15, a new skin is displayed and the user interface of the application is adjusted according to the new device form factor.

Figure 15. A Pocket PC application with a user interface for a simple text editor displayed using the Square Screen form factor

Changing form factors in Visual Studio 2005 is easy. The application does not even need to be recompiled. After all, the device is still a Pocket PC device, so you can still use all Pocket PC–specific controls. The only thing that changes is the layout of the forms during design time.

But what if you want to change to a completely different device? Imagine that you want to use the same application on a Smartphone device.

Changing the Targeted Platform

Changing the targeted platform for a particular application was not really supported in Visual Studio .NET 2003. For instance, when you created an application for a Pocket PC, there was no support in Visual Studio .NET 2003 to change the project to target a Smartphone. The best approach was to separate all business logic from user interface logic, reuse the business logic for the new target platform, and then manually redesign the user interface.

In Visual Studio 2005 it is possible to change the targeted platform. Of course, from a software developer''s point of view, it is still a good idea to separate business logic from user interface logic, but retargeting to a different platform by using Visual Studio 2005 makes you more productive in modifying the application user interface to support different hardware. In fact, if you change the targeted platform, only the user interface will be changed. All other aspects of the application produced by the project are the same. Because several controls that are available on Pocket PCs are not available on Smartphones, the designer converts these controls to the closest matching alternatives that are available on Smartphones.

With Visual Studio 2005, you can change the targeted platform for a particular project. The designer will help you as much as possible to convert the user interface to meet the requirements of the new targeted platform. You can change to a new targeted platform in Visual Studio 2005 by selecting Change Target Platform on the Project menu. When you select this command, a dialog box shows the current targeted platform and a list from which you can select a new targeted platform, as shown in Figure 16.

Figure 16. Changing the targeted platform from Pocket PC to Smartphone

After clicking OK, Visual Studio will change the target project for you. In the process, it closes and reopens your project. The difference is that the form designer now shows your application with Smartphone form factors. Visual Studio has not changed any of your code and all of the original controls are still available on the form, but you may need to resize them to fit in the smaller screen of a Smartphone.

Figure 17 shows you a number of controls that are not supported by Smartphones. You can distinguish controls that are not supported by the targeted platform because they appear on the form with a warning indicator (a triangle with exclamation mark) and their properties are grayed out. Visual Studio 2005 can help you convert unsupported controls to supported controls. When you select an unsupported control in the form and click the arrow shown at the top of the control, a popup menu is displayed with controls that are supported and have comparable functionality as the unsupported control. In case of buttons, as shown in Figure 17, Visual Studio helps to convert them to either text boxes or menu items. If you change a button to a menu item, the menu item will be hooked up to the original button_Click event, meaning that the menu item gets the same functionality as the button in a Pocket PC. In Figure 17 you can also see that the SaveFileDialog and OpenFileDialog controls are not supported on a Smartphone. But these components are different from buttons—there is no simple conversion from these components to alternative Smartphone controls, so you have to do some work to change these controls. In this download code sample, the most likely thing to do would be to provide your own dialogs to open and save files. In the download code sample, these dialogs are not implemented, but hopefully you get the idea.

Figure 17. A Pocket PC application that has been converted to a Smartphone application

After all of the buttons are converted to menu items and when the OpenFileDialog and SaveFileDialog components are removed, you can simply build and run the project. As you can see in Figure 18, the same application now runs on a Smartphone. Changing the targeted platform is an irreversible action. Even though Visual Studio does not change your application code, it will make changes to the layout of the user interface.

Figure 18. Simple text editor now running on a Smartphone

Even though you must do some work to change an application to a different targeted device, the amount of work is, in most cases, less than the work you would have to do to create an entire user interface for another target device.

Visual Form Inheritance

Over the last few years, many device developers have requested visual support for form inheritance. In Visual Studio .NET 2003, visual form inheritance is not supported in smart device projects, although—if you are creative—you can use the C# preprocessor for conditional compilation to give you a rather limited amount of designer support when inheriting one form from another form. Visual Studio 2005 on the other hand gives you full designer support for visual form inheritance. This is a great addition, allowing you to reuse and extend forms without the need to continuously start creating new forms from scratch.

To show visual form inheritance, start with a simple base form that you can later use to derive other forms from. Even though it is not absolutely necessary, it makes a lot of sense to create a separate class library that will hold your base form. If you create a base form as part of your project, it is a lesser candidate for reuse in different applications. Besides that, the form designer in Visual Studio must be able to read metadata of the base form before it can display a form derived from it, meaning that you have to do an extra compilation before you are able to use the base form for inheritance if the base form is contained in the same project as the derived form. Creating the base form in a separate library makes this unnecessary.

It is important to think ahead about the base form; you should especially know which controls you can modify in inherited forms and which controls you cannot modify. To be able to modify controls or the behavior of controls, you must make sure to set the access modifier of the particular control to something other than private. It is not possible to change properties of a private control in the derived form. Figure 19 shows a simple base form that you can use later in an application.

Figure 19. Base form that is stored in a separate class library

The base form contains one private button that executes the same action on each derived form when it is clicked. Because this button is private, neither the button nor its members are accessible in the derived form. The base form also contains a protected button with an event handler implemented as a virtual method. Just like any other virtual method, the event handler can be overridden in individual derived forms. Because of the fact that the second button is protected, both the button and its members are accessible in the derived form. You can even decide to create a separate click event handler in the derived form, resulting in both the base form''s and the derived form''s event handler being executed. Finally, the base form also contains a protected label, meaning the label can be accessed from all derived forms. Note that the base form in Figure 19 does not contain a menu. By default, the designer creates a Menu control named mainMenu1 on each newly created form. It is possible to have a menu in the base form and even extend it in the derived form. However, you would have to be careful to remove the menu on the derived form and set the access properties of the menu in the base class to Protected or Public.

The base form contains some common functionality that will be shared amongst derived forms, as shown in the following code sample.

using System;using System.Collections.Generic;using System.ComponentModel;using System.Data;using System.Drawing;using System.Text;using System.Windows.Forms;namespace BaseFormLibrary{    public partial class BaseForm : Form    {        public BaseForm()        {            InitializeComponent();        }        private void button1_Click(object sender, EventArgs e)        {            label1.Text = "Same action on all forms";        }        protected virtual void button2_Click(object sender, EventArgs 
e)        {            label1.Text = "Default action";        }    }} 

The BaseForm method contains two button-click event handlers. The button1_Click handler is a private method; it can not be overridden. Implementing button1_click as private results in the same action always being executed on each derived form when button1 is clicked. However, it would have been possible to create the button1_Click event handler as protected virtual. In that case, it would have been possible to override the button1_Click event handler in a derived form—giving it specific functionality for that particular form.

The modifiers for the button2_Click event handler are more interesting. Even though the code generated by the Forms Designer created the button2_Click event handler with a private access modifier, you can modify the event hander declaration in the source file. By declaring the button2_Click event handler as protected and virtual, it can be overridden in derived forms, resulting in their event handlers executing when button2 is clicked. If the button2_Click event handler is not overridden in a derived form, the button2_Click event handler of the base form will be executed. This is exactly the behavior you would expect when deriving a class from a base class. Because button2 is declared protected, there is one more possibility that is not shown in the upcoming code samples. With button2 declared as protected, a derived form has access to its properties and events—including the click event. Therefore, it is also possible to add another event handler to the click event, resulting in executing both the base form''s event handler and the derived form''s event handler.

To use the base form, you can create a new smart device project, and add a reference to the BaseFormLibrary assembly in it. When you create a new smart device project that is the Device Application type, the designer automatically adds a form to the project. This form is derived from System.Windows.Forms.Form. To derive from your base form, add a using declaration for the "BaseFormLibary" namespace to the form''s source file and then simply modify the declaration of the form in the source code of the form, for example when you change:

    public partial class Form1 : Form

to:

    public partial class Form1 : BaseForm

you will derive the form in the application from the previously created base form. When you look at the form in designer view, you will see all of the controls from the base class and the controls added specifically for this particular form, as shown in Figure 20.

Figure 20. Derived form that contains controls from the base form with full designer support

The controls that were placed on the base form are inherited on the derived form. You can see that they are inherited because they show a symbol in the upper left corner as shown in Figure 21.

Figure 21. The inherited symbol

You can also see that the middle button is a private button to the base form (meaning it can not be overridden) because it has an additional lock symbol in the upper left corner. Also, the properties of the center button are grayed out because they cannot be modified in the derived form. Of course it is possible to add additional controls to an inherited form.

In Figure 20, the first button is a new button that was added to the inherited form. The entire application, called VisualInheritance in the download code sample, consists of two forms—both are inherited from the base form. The main form overrides the Overridable action button click event handler to display the second inherited form. The second form does not override the click event handler for the Overridable action button, so clicking it will simply execute the default event handler that is provided in the base form. In the following code sample, you can see the source code for the main form of the application.

using System;using System.Collections.Generic;using System.ComponentModel;using System.Data;using System.Drawing;using System.Text;using System.Windows.Forms;using BaseFormLibrary;namespace VisualInheritance{    public partial class Form1 : BaseForm    {        public Form1()        {            InitializeComponent();        }        protected override void button2_Click(object sender, EventArgs 
e)        {            Form2 form = new Form2();            form.ShowDialog();        }    }}

In the previous code sample, you should note several things. First, you can see that, by looking at the class declaration, the form is derived from BaseForm. Second, the event handler for button2 is overridden. If you want to replace functionality of the event handler by new functionality in the derived form, you must override the button2_Click event handler rather then attach a new event handler to it. The code for Form2 is even simpler as you can see in the following code sample. It only contains an event handler for the newly created button3 on the form. When button1 or button2 are clicked in Form2, the event handlers found in the BaseForm execute, as shown in the following code example.

using System;using System.Collections.Generic;using System.ComponentModel;using System.Data;using System.Drawing;using System.Text;using System.Windows.Forms;using BaseFormLibrary;namespace VisualInheritance{    public partial class Form2 : BaseForm    {        public Form2()        {            InitializeComponent();        }        private void button3_Click(object sender, EventArgs e)        {            label1.Text = "Local button clicked";        }    }}

You now should have a good idea about how to use visual form inheritance in combination with the Windows forms designer. Of course, you can host any control on the base form, as long as you want to reuse it in derived forms. Just make sure to change the Modifiers property of the control to protected or public if you want to modify the behavior of the particular control in a derived form. With the Modifiers property set to a value different than private, you can even hide the control, dock it, or resize it on a derived form.

Working with Visual Studio Database Tools

SQL Server 2005 Mobile Edition (SQL Mobile) is the new name for SQL Server CE. When you are planning to work with a SQL Mobile database, Visual Studio 2005 offers you some great features. For the first time, you are able to create your database from within Visual Studio. Prior to Visual Studio 2005, you could only create a SQL Server CE database locally on the device, either in code or by using the version of QueryAnalyzer located on the device. With Visual Studio 2005, you can use the integrated Visual Database Tools to create your database. You also have the ability to fill your database with data and create typed datasets.

In this section you will get an overview about how to work with data by using Visual Studio 2005. This article does not provide a complete discussion about how to work with SQL Mobile; it is limited to showing the Visual Studio database tools. However, to put everything in perspective, you will learn how to create a SQL Mobile database from within Visual Studio, how to use that database in a simple application, and how to create typed datasets to populate controls by using data binding.

To create a SQL Mobile database in Visual Studio 2005, you can use the Visual Studio 2005 Server Explorer. It is possible to add a new SQL Mobile database to an existing project, modify the schema of an existing SQL Mobile database, populate a SQL Mobile database with data, and examine a database that is already deployed on the device by using ActiveSync version 4.0.

You should begin with a new project and create a simple database to use inside the application. The database you are going to create is a simple DVD collection database. For sample purposes, it is very simple; it only contains DVD titles and categories. The database is made up of two different tables: DVD_Titles and DVD_Categories. By using Server Explorer, you can create the database locally on your development computer. Later, you will find out how you can add the database to your project, so it will be deployed with the application to the device.

There are several ways to create a SQL Mobile database inside Visual Studio 2005. To create a database by adding a new data connection to your project, right-click Data Connections in Server Explorer, and then select Add Connection, as shown in Figure 22.

Note If Server Explorer is not already visible within Visual Studio 2005, open it by clicking View, and then by clicking Server Explorer on the Visual Studio 2005 menu.

Figure 22. Adding a database connection to a smart device project

Visual Studio displays a dialog box to add the connection, as shown in the left graphic of Figure 23. In this dialog box, you can attach to an existing SQL Mobile database or you can create a new database. As long as the device is connected by means of ActiveSync, you can create a database on a connected device or you can even attach to an existing database on the device. If you are creating a new database, first create it locally on the development computer and then deploy it as part of your application to the device.


Figure 23. Creating a new local SQL Mobile database by using the Add Connection dialog box (left) and the Create New SQL Server 2005 Mobile Edition Database dialog box (right)

In the Add Connection dialog box, you can either browse for an existing database or create a new database. When you click the Create button, the Create New SQL Server 2005 Mobile Edition Database dialog box displays. In Figure 23, the new database is created in the My Documents folder on the desktop computer. Also in this dialog box, you have options to encrypt the database and to add a password for security. In this article, the only thing you will do is specify the database name MyDVDCollection. When you click OK, Visual Studio 2005 creates the database. You can verify the connection to the database by clicking the Test Connection button.

Assuming you have a working connection, next you will create tables in the database. In Server Explorer, you will see the newly created database under Data Connections. If you expand the database, you will find a Tables entry. To create a new table, right-click Tables, and click Create Table, which displays the New Table dialog box, as shown in Figure 24.

Figure 24. Creating a table to add to a database

You can create tables to add to your database and set the column names, data types, and other column-specific attributes for the particular table. After you click OK, the new table is added to the database. You can create multiple tables by using this dialog box.

So far, you have not written any lines of code for the application. You have used the data designer tools of Visual Studio to create a database with a number of tables in it. You can enter data in the newly created database from within Visual Studio in Server Explorer. To enter data in a table, select and expand the database in Server Explorer, expand the Tables node and right-click on a table to Open it by opening the individual tables in Server Explorer and starting to add data to them, as shown in Figure 25.

Figure 25. Adding data to a table

To use the newly created database in an application, you need to add a data source to the application. In Visual Studio 2005, select the Add New Data Source entry on the Data menu. This action activates the Data Source Configuration Wizard, as shown in Figure 26.

Figure 26. Choose a data source type by using the Data Source Configuration Wizard

The first page of the wizard is used to select a data source type. This data source type indicates whether the data will be retrieved from a database, Web service, or application object. In Figure 26, the data source type is a database. Next, you need to choose the data connection. The wizard displays existing connections you can select from, as shown in Figure 27. You can also create a new data connection from within the wizard. If you need to create a new data connection, you can click the New Connection button. You''ll need a new connection when you don''t have an existing database or you are working with a particular database for the first time. This button opens the Add Connection dialog as shown in Figure 23. Because you already have an existing database—MyDVDCollection—on the development computer, you can select that database in the Data Source Configuration Wizard. The wizard asks if the database should be added to the current project, as shown in Figure 27. If you click Yes, Visual Studio 2005 takes a copy of the database, adds it to the project, and deploys it with the application when you run the application from within Visual Studio 2005.

Figure 27. The message prompts you to decide if the database you''ve chosen should be added to the connection

The Data Source Configuration Wizard creates a typed dataset that you can use to bind data to controls in the application. There are other data binding options available as well. However, they are beyond the scope of this article. So, in this example, you will use a dataset. Datasets are objects that contain data tables where you can temporarily store the data for use in your application. When a dataset is created, Visual Studio generates code to access data in the dataset, to edit data in the dataset and to transfer data back and forth between the database and the dataset. This limits the amount of code you have to write. Because this application only shows data that already is available in the database, you do not need to write any code. The entire application functions with generated code.

Finally, you need to choose which database objects are going to be part of the dataset the wizard is about to create, as shown in Figure 28.

Figure 28. Choose the database objects by using the Data Source Configuration Wizard

To have all of the data that is inside the dataset available, you can simply select all of the tables. After you click Finish, the wizard creates a typed dataset that you can use to display data from the database in the application, which uses data binding to bind individual data items to user interface controls. The application that will use the MyDVDCollection database simply displays a list of the available DVD titles in a datagrid control and uses a parent–child relation to display the corresponding categories.

You need to define the relation between the list table containing DVD titles and the table containing categories in the dataset. Again, this is something you can do using a Visual Studio 2005 designer, in this case the DataSet Designer, as shown in Figure 29.

Figure 29. DataSet Designer

You can open the DataSet Designer by right clicking the MyDVDCollectionDataSet.xsd file in Solution Explorer, and then by choosing View Designer; alternatively you can open the DataSet Designer by right-clicking one of the items that are visible in the Data Sources pane and selecting Edit DataSet with Designer, as shown in Figure 29. If the Data Sources pane is not visible, you can open it by selecting Data Sources on the Data menu.

In the DataSet Designer, you will see a visual representation of tables that are part of the dataset. To create a relation between different tables, select a field in one of the tables that joins the tables together, and then drag it to the other table that needs to be part of the relationship. This action makes the Relation dialog box appear. In this dialog box, you specify the fields that relate the tables in the dataset. For this example, DVDTitles is the parent table, DVDCategories the child table, and they are related by the DVD_CategoryID field as you can see in Figure 30. You can also show the Relation dialog box by right-clicking one of the tables, by pointing to Add, and then by clicking Relation.

Figure 30. Defining the relationship between two tables

With the database in the project, a dataset created for the database, and the relationship defined in the dataset, the only thing left to do is make the data visible inside the application. Because this example is extremely simple and is meant to show the Visual Studio designers that help you create applications that use a SQL Mobile database, the user interface itself is nothing fancy. It simply is made up of a DataGrid control containing DVD titles and a Textbox control to show corresponding categories for each DVD title. In the Data Sources pane, you can select a specific user interface control for each column or for an entire table. To do so, click the column or table that you want to display on a firm. After that, you can expand the user interface controls that can be used to make data visible by clicking the down-arrow button. Next, select the user interface control that you want to show on the form, and then drag it to the form, as shown in Figure 31. Controls that you add to the form in this way are automatically bound to the underlying data, so you don''t need to write any code to display the contents of the data that is currently available in the database.

Figure 31. Adding data bound controls to the application

To be able to use the existing relationship between DVDTitles an DVDCategories, you can drag the DVD Category field from the child table, which is displayed under the DVDTitles table. When you compile and deploy this application, the database is deployed to the device with the application, and you can immediately use it, as shown in Figure 32.

Figure 32. The completed DVD collection application

Of course, you will need to add some code if you also want to add new records, delete records, or modify records from the database—but these actions are beyond the scope of this article.

Conclusion

With Visual Studio 2005 and the .NET Compact Framework version 2.0, you have a large number of controls available out of the box that will immediately increase your productivity. The new user interface designer can help you create great user interfaces. Thanks to the availability of skins in the designer, you immediately get a feeling of what your user interface will truly look like on an actual device. You can even test the appearance of your user interface in portrait and landscape modes (when applicable) without the need to write any lines of code. The availability of data designers allows you to create and maintain SQL Mobile databases on a development computer and deploy them to the device afterwards. This article exemplified some of the capabilities of Visual Studio 2005 with regards to design tools. There are many more features to explore, and hopefully you are curious enough to explore the many other features of Visual Studio 2005 on your own.

转自: http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dnppcgen/html/ui_data_designers_netcf2.asp