Archive for the ‘Debugging’ Category

Creating a Redfly emulator

Monday, January 14th, 2008

The Redfly Mobile Companion (manufactured by Celio Corporation) is essentially a large external LCD screen and keyboard designed to display the contents of an attached Windows Mobile based PDA or smart-phone. One value proposition of the device is to improve the usability of applications such as Excel Mobile in large part due to the device’s 800×480 screen which enables more data to be displayed. If any device embodies the intent behind Microsoft’s Adapt Your App campaign and how far we have came from the days of a single 240×320 screen resolution this may be it.

Recently I became interested in understanding how well various applications coped with the Redfly’s larger screen resolution, as I imagine supporting such a resolution isn’t in the front of most developer’s minds at the moment. Not having access to a physical device I decided to configure the Windows Mobile Device Emulator to approximate the behaviour of a Redfly device.

Screenshot showing Excel Mobile running on a device with a 800 x 480 screen

Creating a custom emulator
Visual Studio uses an applicaton called Device Emulator for the emulation of ARM based Windows Mobile or Windows CE devices. This application is designed to also be used standalone (you can download it from Microsoft Downloads) and accepts a number of command line arguments to configure the emulated PDA.

To start a Windows Mobile 5.0 Pocket PC emulator with the same screen resolution of a Redfly device we could use the following command line:

"C:\program files\Microsoft Device Emulator\1.0\DeviceEmulator.exe"
  "C:\Program Files\Windows Mobile 5.0 SDK R2\PocketPC\DeviceEmulation\0409\PPC_USA.bin"
  /cpucore ARMv5
  /memsize 256
  /s "C:\Development\RedflyEmulator.dess"
  /tooltips ON
  /vfp false
  /video 800x480x16
  /vmname "Redfly Emulator"
  /speakerphone 7

Some of these paths may need to be altered to suit your installation of Visual Studio and the various Device SDKs. Full details on the meaning of the various command line arguments can be found on the Device Emulator Command-Line Reference page within MSDN.

Reusing a custom emulator
Screenshot showing Device Emulator Save State file (*.dess) within Windows ExplorerOnce a custom emulator has been started via the command line shown above you will be prompted when you attempt to exit the emulator to save the current state. If you select Yes to this prompt a Device Emulator Save State (*.dess) file will be created. This file contains a complete snapshot of the emulator’s configuration and memory contents. Double Clicking on this file within Windows Explorer will automatically launch the Device Emulator and restore the emulator back to the state it was in before you exited. There is no need to re-enter the rather long command line again.

Summary
Creating a custom emulator enabled me to determine the enhanced usability (or lack there of in some cases) of various Microsoft and Third Party applications on a device with the Redfly’s form factor. I could defiantly see the advantage of the larger screen in applications such as viewing and creating Excel spreadsheets (as demonstrated in the above screen shot). However other applications (such as Pictures and Videos) didn’t really take full advantage of the additional screen real-estate. Moving forward it would seem to be advantageous for ISVs to consider how to dynamically take advantage of extra screen real-estate when presented with a device such as the Redfly. In fact I see some real business oppertunities for those that truely take advantage of it.

Creating custom emulators as demonstrated in this blog posting is also useful for producing presentation material for Sales people. By making various save state snapshots it is possible to present your application in a number of different configuration/use case scenarios without constantly needing to reconfigure the standard emulator and it allows you to quickly revert back to a known good starting state for your demos.

Using $exception within Visual Studio’s Debugger

Tuesday, December 4th, 2007

Here is a little tip that I discovered today. Quite often you will develop exception handling code that looks like the following:

try {
  // do something here which may fail
}
catch (FileNotFoundException) {
  // do some error handling here which
  // doesn't refer to the exception object
  // that has been thrown
}
catch (Exception) {
  // do some more generic error handling here
}

Since our exception handling code makes no use of the exception object that has been thrown, we do not need to declare a variable to reference it (i.e. the traditional “ex”). However this leads to an issue while debugging. Without a variable there is nothing to mouse over in order to display the exception’s contents once the initial popup has been dismissed.

Up until today I would typically modify the code to look like the following:

try {
  // ...
}
catch (FileNotFoundException ex)
{
  // ...
}

This allows me to mouse over the variable ‘ex’ in order to view the contents of the exception. However this meant that I needed to modify the source code and restart the debugging session (hoping I could re-create the error condition). It also meant that a compile time warning (”CS0168: The variable ‘ex’ is declared but never used.”) was produced, since the compiler correctly points out that I am not using this variable.

What I learnt today was that instead of doing this you can add the special variable $exception to the debugger’s Watch Window, or query it via the Immediate Window. This variable references the currently thrown exception when located within a catch block.

Screenshot of Visual Studio 2005 IDE showing the Watch Window display the value of the $exception variable

Now for the bad news, unfortunately this tip only seems to work for applications targeting the full Desktop framework, when developing a Smart Device or .NET Micro Framework project the watch window reports “The name ‘$exception’ does not exist in the current context”.