You Can Take It with You

Article
10/26/2006

Jim Wilson
JW Hedgehog, Inc.

July 15, 2002

Download the ScrollEvents.exe sample file.

***Note from Chris Sells *Running a Windows Forms application on a desktop or laptop computer is cool, but with the imminent release of the .NET Compact Framework, we'll soon be able to run Windows Forms applications on much smaller devices, ranging from your average palmtop down to even smaller form factors like a cell phone. Since I have an intimate relationship with both my Windows Forms and my cell phone, I'm very interested in learning how to bring the two together. Nobody knows more than Jim Wilson about bringing these two technologies together, and he's been gracious enough to step in as a guest columnist this month to cover the topic.

Mobile computing technology has been moving at a lightning pace. Things like smart phones, hand-held computers, and wireless networks are everyday features of life. While we live in a world of mobile hardware approaching the likes of an H.G. Wells novel, we're still searching for the software that will truly empower these devices. The problem isn't from a lack of effort. Developing truly mobile software has historically been much more difficult then desktop software. The screens are small, memory and CPU are a fraction of the desktop, and the mobile developer just didn't have the same level of development tools as the desktop developer. I personally have spent months building an application targeting mobile devices that would have taken little more then a few weeks if I had been targeting the desktop. Many a mobile device developer (this one included) have worked long into the night while wishing we had those cool productivity tools that desktop developers get to use. Well finally, the .NET Compact Framework and Smart Device Extensions have made that wish come true.

So what's this got to do with Windows Forms? Windows Forms empowers developers to create rich user applications. Mobile devices empower users by literally putting computing power in a mobile device. The .NET Compact Framework, combined with Smart Device Extensions, give developers the tools we need to develop rich Windows Forms applications that our users can carry in the palm of their hand.

What's this All About?

Before we delve into the details, let's clear up the terms. The .NET Compact Framework and Smart Device Extensions are actually two completely different (although related) pieces of software. The .NET Compact Framework ( .NET CF) is the subset of the .NET Framework (runtime and libraries) that runs on smart phones, Pocket PCs, and other resource constrained devices. Smart Device Extensions (SDE) are the tools that plug into Visual Studio® .NET to simplify the development of .NET CF applications.

When developing applications that target the .NET CF, we use the same C# and Visual Basic® .NET languages as the desktop. With SDE installed, we even use the same Visual Studio .NET. The .NET CF classes are the same .NET classes we use for the desktop, although due to the resource constraints of mobile devices, the .NET CF classes are a subset. The two environments are compatible. I often have Visual Studio .NET solutions that contain both desktop and mobile projects.

Getting Started

To get started, download and install SDE. Installing SDE also installs the .NET CF so you are now ready to start building mobile applications. If you've ever written a .NET Windows Forms application, then you know all that you need to start writing mobile applications. In fact you don't even need a mobile device because the SDE includes a full-function emulator that lets you run and test your code exactly as if you had an actual device.

Opening Visual Studio .NET after completing the install shows very little change. In fact, you won't notice much difference at all until you open the New Project dialog. Under both Visual Basic Projects and Visual C# Projects, there now appears a Smart Device Application entry as shown in Figure 1.

Figure 1. Visual Studio .NET New Project dialog after installing Smart Device Extensions

Choosing Smart Device Application and clicking OK leads you into the Smart Device Application Wizard. It's a simple wizard consisting of one dialog that contains two questions: target platform and project type.

Figure 2. Visual Studio .NET Smart Device Application Wizard dialog

Projects generated with the Smart Device Application Wizard are specifically targeted to run with the .NET CF. The currently supported .NET CF platforms are Pocket PC 2000 and Pocket PC 2002 and Windows® CE .NET. I suggest sticking with the Pocket PC as the majority of both consumer and business devices are Pocket PC based. The only exception would be if you are writing an application targeting a specific device, such as a custom barcode scanner or other special hardware that you know runs Windows CE .NET. The differences between a Pocket PC and Windows CE .NET project are minimal and are primarily cosmetic, so most software will run unchanged on both.

The project type choices are self-explanatory. They're a subset of the choices on the regular New Project dialog. Choosing Windows Applications creates a Windows Forms application similar to the desktop. When creating a Windows Application, the only notable difference between the Pocket PC and Windows CE platforms is that a Pocket PC project is automatically created with a menu bar, whereas a Windows CE project is created without one. This subtle difference stems from the fact that Pocket PC applications tend to be general purpose applications that support a variety of functionality, whereas applications targeting Windows CE.NET are more likely to be designed for the specific tasks supported by special purpose devices. In either case, once the project is created, menus can easily be added and removed using the forms designer.

Setting the platform to Pocket PC and project type to Windows Application results in a project that looks similar to Figure 3. It should look pretty familiar. In fact, from this point the interaction is almost identical to a desktop application. Controls are added to the form by dragging them from the toolbox. Controls are customized by setting values in the Properties window. Double-clicking a control attaches the default event.

Click here to view Figure 3

Figure 3. Newly Created Pocket PC Project

What's the Difference?

So does this mean that you can take all of your existing desktop Windows Forms code and have it magically run on hand-held computers and smart-phones? Well, not quite. Mobile devices require some special consideration.

First there's the display size. A user interface designed for a 17-inch monitor is not going to translate well to the 3.5-inch display of a Pocket PC or the 1.5-inch display of a mobile phone. Mobile applications should limit controls to those that render well on small form factors.

Even more important then display size is the limited memory and CPU resources of mobile devices. To give you a sense of the challenge Microsoft faced, consider that most desktops have 128 megabytes (MB) or more of physical RAM with a virtual address space that is easily two or three times that. A Pocket PC often has only 16 MB of total address space. A smart phone may have even less.

The resource constraints are further magnified by differences in application life cycle. Mobile devices are not just smaller versions of desktop computers. Users interact with these devices very differently from their desktop cousins. Normally, a desktop application is started when the user wants it, and exited when the user is done. Most mobile device applications don't operate this way. They instead operate in an always-ready mode. An applications that runs in always-ready mode is started the first time a user accesses it, and then from that point forward stays around ready for the user in the exact state it is left. Many popular Pocket PC applications such as Calculator, Pocket Outlook, and Money run in always-ready mode.

These resource constraints mandate that the .NET CF be a subset of the full .NET Framework. There is simply no way that the full .NET Framework would fit. Microsoft has done an amazing job of trimming things down. The .NET CF footprint is literally less then 1/10^th the size of the full .NET Framework.

From a Windows Forms standpoint, much of the savings is found by limiting the supported controls to those that render well on smaller form factors. Don't be worried; there are over 20 supported controls as shown in Table 1.

Button	ListView	StatusBar
Checkbox	MainMenu	TabControl
Combobox	NumericUpDown	TextBox
DomainUpDown	Panel	Timer
HScrollBar	PictureBox	TrackBar
Label	ProgressBar	TreeView
ListBox	RadioButton	vScrollBar

Table 1. Compact Framework/Smart Device Extensions Supported Controls

The supported controls, while consistent with their desktop counterparts, have been simplified. Much of the simplification comes from the removal of features that don't translate well to small form factors, like drag-and-drop. Further savings are achieved by removing redundant events and methods.

Dealing with the Differences

The .NET CF and SDE are designed to minimize the impact of differences between the .NET CF and the full .NET Framework. Overall, they have done an good job. The .NET CF Windows Forms classes are the same classes that are on the desktop. .NET CF development supports the full Visual Basic .NET and C# languages. Thanks to SDE, .NET CF development is fully integrated into Visual Studio .NET. .NET CF applications use the Visual Studio .NET debugger and can be debugged directly on the device or using the supplied emulator. There is, however, no way that all of the differences can be transparent.

The always-ready" mode is unfamiliar to most desktop developers, but is very popular for mobile applications, so SDE projects are generated this way by default. Always-ready applications are great for users, but for developers, debugging requires that we start and stop applications frequently. During the debugging process, the only way to stop an always-ready application is to use the Stop Debugging menu option in Visual Studio .NET or to go to the device's Running Programs screen and kill the application. For this reason, I recommend turning off the always-ready behavior during development.

Figure 4 shows an always-ready, SDE-generated Pocket PC Windows Application running in the Pocket PC emulator. With the exception of the "Pocket PC Emulator" title bar and the menu bar just below it, this is exactly how the application will appear on an actual Pocket PC.

Figure 4. An always-ready Pocket PC application running in the emulator

Looking at the application window, the only indication that it is running in always-ready mode is the small icon to the right of the time display that looks like a circle with an X in the middle. It would seem logical that clicking (tapping in Pocket PC terms) that icon would exit the program, but this is not the case. The icon is actually the Pocket PC minimize box. Tapping it causes the application to go into the background while continuing to run.

Turning off always-ready mode during the development progress is easy, although the process isn't obvious. There is no always-ready property. Instead the always-ready behavior is controlled by the MinimizeBox property of the application's main form. Figure 5 shows an SDE Windows Application project in Visual Studio .NET with the application form's properties set to their default values.

Click here to view Figure 5

Figure 5. Smart Device Extensions application form's default properties

Changing the MinimizeBox property to false replaces the applications minimize box with an OK box. The application now looks like Figure 6 when run in the emulator and tapping the OK box exits the program.

Figure 6. Pocket PC application with always-ready mode disabled

If you would prefer not to have to remember to change the MinimizeBox property each time you switch from a debug to production build, the following code shows how to modify the form constructor so that the application will automatically switch always-ready mode off for debug builds and on for production.

public Form1() {
  InitializeComponent();

#if DEBUG
  this.MinimizeBox = false;
#else
  this.MinimizeBox = true;         
#endif
}

Occasionally, when moving to the .NET CF, you may discover that a method or event you use on the desktop is not supported on the .NET CF. In most cases, the method or event isn't available because its functionality is redundant to another method or event. A good example of such a case is the Scroll event on the ScrollBar class.

Let's assume that we are building a desktop application that has a simple form containing a scroll bar and a text box. Each time the scroll bar moves, we want to update the textbox with the scroll bar's current value. The easiest way to handle this in Visual Studio .NET is to double-click on the scroll bar and let Visual Studio .NET create the default event handler. For a desktop application, this is the Scroll event. In the event handler, we extract the scroll bar value from ScrollEventArgs and then update the text box. Here's the code (see downloads for Visual Basic .NET example).

void hScrollBar1_Scroll(object sender, ScrollEventArgs e) {
  int currentPos = e.NewValue;
  this.textBox1.Text = currentPos.ToString();
}

To build the same application targeting the .NET CF, drag a scroll bar and text box onto the form, then double-click the scroll bar to add the default event. The default event handler is added but with one slight surprise—the default event on the desktop was Scrollhas changed to ValueChanged. In fact, the .NET CF scroll bars don't raise the Scroll event at all, even though the desktop supports both.

Although this may seem strange, the Scroll and ValueChanged events are closely related. Scroll bars fire the ValueChanged event every time the scroll bar's Value property changes, regardless of whether it's programmatically or as the result of the user moving the scroll bar. On the desktop, the Scroll event fires when the user moves the scroll bar and is always preceded by a ValueChanged event. The primary information delivered with the Scroll event is the new value of the scroll bar, which can easily be determined in the ValueChanged event. These factors make the Scroll event a perfect candidate for exclusion. In addition, the scroll event passes an argument, ScrollEventArgs, which is a specialized class used by no other events in the .NET CF, therefore excluding the Scroll event not only reduces the size of the .NET CF footprint, but also further reduces it by eliminating the need for the ScrollEventArgs class.

We'll go ahead and use the ValueChanged event in our .NET CF application. As with most events, the first argument is a reference to the object that raised the event, so we'll cast the reference to an HScrollBarreference and ask the scroll bar for its Value directly. Here's the ValueChanged handler code for our .NET CF application.

void hScrollBar1_ValueChanged(object sender, EventArgs e) {
  int currentPos = ((HScrollBar)sender).Value ;
  this.textBox1.Text = currentPos.ToString() ; 
}

We don't encounter situations like this a lot, but they do come up. In most cases, a little open mindedness identifies a few simple changes that will allow us to achieve the desired result. And the best part of all, the Windows Forms library in the .NET CF is a true subset of the full Windows Forms library, so the code that runs on .NET CF will also run on the desktop, making it possible to create libraries that can be shared on both platforms.

Where Are We?

I've only covered the bare essentials of the Windows Forms support in the Compact Framework. If you would like to learn more, the best place to start is with the product documentation that is automatically installed and integrated into the rest of the Visual Studio .NET help system when Smart Device Extensions are installed. For online resources, check out the References section.

The .NET Compact Framework provides a platform to run and deploy powerful mobile applications and Smart Device Extensions for Visual Studio, and gives developers the productivity tools we need to build them. Combined, we finally have what we need to build robust applications that can truly give users the power to manage information anytime, anywhere.

You Can Take It with You

What's this All About?

Getting Started

What's the Difference?

Dealing with the Differences

Where Are We?

References

Further Reading

Additional resources