Migrating Applications to the .NET Compact Framework c2.0 and Windows Mobile 5.0


Windows Mobile developers have had much to be excited about in recent weeks. With the release of Windows Mobile 5.0 to device manufacturers, there are a number of new features and functionalities made available to both new and existing (if upgraded) Pocket PCs and Smartphones. The .NET Compact Framework 2.0 is expected to be available in conjunction with the release of Visual Studio 2005, expected for release on November 7th and currently in beta. While there are a number of opportunities for Windows Mobile developers based upon these two important announcements, there is also a lot to consider.

For most application developers, the move to new versions of a development tool, technology, or operating system brings with it the challenges of compatibility. Usually, there are the critical concerns over whether an application can even run in the new environment, followed by changes that affect performance and usability. For Windows Mobile developers, these concerns are quite valid. Changes to the .NET Compact Framework 2.0 can pose some problems for any existing applications, while Windows Mobile 5.0 poses some additional issues. The first part of this article will break down some of the major considerations for migrating your applications to the new version of the framework, allowing you to get a “head start” on preparing your application to function properly when Windows Mobile 5.0 and the Compact Framework 2.0 are generally available.

The Compact Framework 2.0

The best place to start in understanding impacts on your existing Windows Mobile applications is with some general changes to the .NET Compact Framework in Version 2.0. These changes might seem minor at first, but they can have a significant impact on your application’s behavior.

Screen Orientation-Awareness

Windows Mobile 2003 Second Edition introduced native support for screen rotation, allowing applications on a Pocket PC or Phone Edition to be viewed in either portrait or landscape orientation. As a developer, you had the ability to write C# or VB .NET application logic to determine screen orientation and rearrange objects within a Windows Form programmatically. You also could just leave the code unaltered, and default behaviors within the runtime environment would automatically add scrollbars to forms when needed to allow the user to have access to all objects on the form. This “legacy screen emulation mode,” as Microsoft refers to the behavior in the Windows Platform Migration FAQ (http://msdn.microsoft.com/mobility/windowsmobile/default.aspx?pull=/library/en-us/dnppcgen/html/migration_developers_faq.asp#migration_developers_faq_topic34), is no longer supported in Visual Studio 2005 or the Compact Framework 2.0. What this means to you as a developer is that your users changing the screen orientation from portrait orientation to landscape may not be able to access all objects within a given Windows Form. Fortunately, there are some relatively painless solutions to this issue.

You can change the AutoScroll property for a Windows Form to be true either at design-time or runtime for your application. Figure 1 shows the Property Sheet for a Pocket PC Windows Form in Visual Studio 2005.

Figure 1: AutoScroll property for a Windows Form

This would provide a “front-line defense” for your application’s form to enable basic usability.

Another (and more granular) option introduced in the .NET Compact Framework 2.0 is the use of the Dock and Anchor properties available to user interface objects. If you have developed Windows Forms applications for the full .NET Framework, you are probably already familiar with these properties. Anchoring an object allows you to set the relative X and Y co-ordinates for an object in relation to their parent container (in this case, a form) such that regardless of the parent object’s dimensions, the user interface object will adhere to this relative positioning. Docking a user interface object goes a step further by resizing the object based upon the dimensions of its parent container. Once again, these properties can be changed at both design-time and runtime. Figure 2 shows a button object’s property sheet with the Dock and Anchor properties displayed.

Figure 2: Dock and Anchor properties

The Dock and Anchor properties provide a very solid and easy to implement solution for dealing with screen orientation-awareness and usability.


Another legacy behavior that has been removed from Visual Studio 2005 and the Compact Framework relates to VGA-enabled devices. A VGA device can support higher-resolution graphics than a standard QVGA screen, as well as increased screen real estate. To support legacy applications, a technique known as “pixel doubling” was employed. It essentially doubled the pixels of objects running on a VGA device for the display (and object positions) to match that of a QVGA device. Prior to Visual Studio 2005, a developer who did not want this behavior to occur actually ran a separate command-line utility (hires.exe) against their application to allow the application to be visualized as they had written the code.

If you expect your application to be run on VGA-enabled devices, you will have some serious design decisions regarding migrating to Visual Studio 2005 and the .NET Compact Framework 2.0. Although docking and anchoring can still help you with this issue, the fact that graphics will now display at half the size of their QVGA counterparts might pose a readability issue for end users. There are programmatic options available to you, including:

  • Writing application logic to determine screen resolution
  • Using multiple sets of images, supporting both QVGA and VGA, and loading the images at runtime
  • Changing font sizes based upon screen resolution
  • Changing object positions within a form based upon screen resolution

The easiest way to determine screen resolution at runtime is by using a new property available to Windows Form objects, the CurrentAutoScaleDimensions property. This property returns a SizeF structure (from the System.Drawing class) which then can be queried. The following C# code provides a basic example:

SizeF currentScreen = this.CurrentAutoScaleDimensions;
if (currentScreen.Height == 192)
   // Your VGA device logic here.

The Height property contains the Dots-Per-Inch (“DPI”) of the current form. 96 is the DPI of a QVGA screen, whereas 192 is DPI for a VGA screen.

The Windows Mobile 2003 Second Edition Resource Kit (http://www.microsoft.com/downloads/details.aspx?familyid=6a34dc83-c3ce-4a4c-ab83-491fd5729551&displaylang=en) and the MSDN Mobility and Embedded Developer Center (http://msdn.microsoft.com/mobility) both have useful information regarding how to programmatically deal with resolution-awareness in your Windows Mobile applications.

More by Author

Must Read