In Professional Edition (Pocket PC) devices the Clock control panel allows you to set a home timezone and a visiting zone and lets you toggle between them. If you need to retrieve the current settings they are stored in the registry in a key called HKEY_LOCAL_MACHINE\Software\Microsoft\Clock in a binary value called "AppInfo". Here is breakdown of that data:-

00,00,00,00,31,00,00,00,55,00,00,00,00,00,00,00,01,00,00,00,80,01,00,00,be,00,00,00,00,00,00,00,00,00,00,00

The first 4 bytes contains an integer which is 1 if in the home zone, and 0 if visiting.

The next 4 bytes always seems to be 0x31

The next 4 bytes are the index into the timezone collection of the home zone (In this example 85 GMT)

The next 4 bytes are unused

The next 4 bytes indicate whether to use DST (In this example 1 true)

The next 4 bytes are always 0x180

The next 4 bytes are the index into the timezone collection of the visiting zone (in this example 190 - New Delhi)

The next 4 bytes are unused

The next 4 bytes indicate whether to use DST in visiting zone (In this example 0 false)

I suspect that the unused values may be connected to the old Cities feature which was originally in the control panel but removed with PPC2003. You may be wondering how to get the timezone information at the specified indexes - in Windows Mobile they are not all stored in the registry as on other Windows CE flavours. They are accessible through POOM - IPOutlookApp.GetTimeZoneFromIndex, or in managed code in Mobile In The Hand.

With Windows Mobile 5.0 AKU2.0 (Messaging & Security Feature Pack) a new feature was implemented called RemoteWipe. This allowed an administrator to remotely wipe a device if it may have got lost and was designed to remove all sensitive data from the device and return it to a fresh state. It was only with Windows Mobile 6 that the details of the implementation were added to the SDK documentation. Like most other administration and device management features RemoteWipe is implemented as a Configuration Service Provider, this allows it to be activated either via remote or local means. For example you could build a mechanism into your software where you wish to wipe the device, perhaps after an extended number of failed password entries etc. Whether you can call the CSP will depend on the particular security policy on the device, however if possible you can initiate a wipe locally with either DMProcessConfigXML or the managed ConfigurationManager e.g.

System.Xml.XmlDocument xd = ConfigurationManager.ProcessConfiguration(cd, true);

Of course you use this code snippet at your own risk, if it works successfully it will wipe data from your device and return to factory fresh condition!

More details about the service provider here:-

http://msdn.microsoft.com/en-us/library/bb737595.aspx

There may be an occasion where you want to restore the original chronological view for the SMS Inbox rather than the new threaded view. One example is where a system programmatically moves or inserts SMS messages into the system because these are not visible in the threaded view (even though the count of unread messages increases). There is a simple registry fix to turn off threading and restore the "classic" view. From the registry editor of your choice browse the device registry for the key:

[HKEY_CURRENT_USER\Software\Microsoft\Inbox\Settings]

Under this add a new DWORD value called "SMSInboxThreadingDisabled" and set it to 1. Close the tmail.exe application or soft-reset the device and the regular message view will be used. Set this registry value back to 0 or delete it to restore the default threaded view.

The release of Windows Mobile 6.1 brings a number of improvements for users but retains the same SDK and libraries as 6. The devices ship with .NETCF 2.0 SP2 in ROM. 

This release adds additional screen resolutions to both the Professional (touchscreen) and Standard (non-touchscreen) editions. For Standard edition these are all 131 dpi and consist of 320x320 square and 400x240 and 440x240 landscape. For Professional there are 240x400 and 480x800 portrait screens. Once again these additional screen sizes emphasize the importance of making sure your app dynamically adjusts to make best use of screen space, for example using the Windows Mobile Line of Business Accelerator 2008.

The images (currently US English only although localised versions should follow) are available to download here:-

http://www.microsoft.com/downloads/details.aspx?FamilyID=3D6F581E-C093-4B15-AB0C-A2CE5BFFDB47&displaylang=en

One of the new features in v3.5 of the Compact Framework is the ability to easily detect the platform you are running on from Smartphone (Standard Edition), PocketPC (Classic or Professional Editions) or WinCEGeneric (Everything else). The code is very straight-forward:-

using Microsoft.WindowsCE.Forms;

if(SystemSettings.Platform == WinCEPlatform.Smartphone)
{
   //do something smartphone specific...
}
 

In the latest (v3.0) version of Mobile In The Hand I've implemented a matching property, so for the above code sample you'd just change the using statement to use InTheHand.WindowsCE.Forms and the code would work the same way. This is available in both the .NETCF v1.0 and v2.0 builds of the library.

A number of customers have been reporting issues with SMS interception on the T-Mobile Dash handset. On these devices the SMS interception does not work through either the Microsoft or In The Hand class libraries. This is specific to the T-Mobile ROM as other branded versions of the same device, such as the HTC S620, do not have the problem. The culprit is a badly behaved IMessageFilter implementation which stops the standard interceptor from working. You can fix this issue by removing the entry from the registry. Take a look at this registry key:-

HKEY_LOCAL_MACHINE\Software\Microsoft/Software/Inbox/Svc/Sms/Rules

In here you'll find 2 entries by default on Windows Mobile 5.0:-

{1000BC1C-F4A3-4210-B197-4AEBF2CEE6F5}

{77990A0E-60B8-4103-B9AF-17157E4274FD}

If you find additional entries here try deleting them (make a backup first so that you can restore if necessary) then reset the phone. This should allow the normal SMS interception mechanism to work again.

On Windows Mobile 6 the above registry key is not present by default, therefore the standard SMS interception will work without any additional rules registered.

Late last week HTC quietly released the Windows Mobile 6 upgrade for the S620. A few eagle eyed bloggers posted about it. The first thing I found was that the upgrade process doesn't work with Windows Vista, when it reboots the device into bootloader mode the computer fails to connect. I had to run the upgrade from a Windows XP machine (where it worked flawlessy). Upon rebooting I had a fresh clean Windows Mobile 6 device. I noticed that HTC had left the default "Mobile Operator" screen during boot up, only after running its initial setup was this removed. Everything was working great, I was able to setup my exchange server in ActiveSync and get all my PIM data back onto the device. The lock dialog is slightly altered in this release, rather than tapping the right softkey to cancel you have to tap the right soft-key to open the menu and select the second option (option 1 is "Reset Password" but is disabled). The reason I often cancel this screen is because I just want to check the home screen for the time / next appointment. The time can optionally be displayed on the unlock screen but only for the key lock, I no longer use that because my exchange provider enforces a password.

There are a few fancy UI features, the improvements to the calendar day screen are welcome along with the ability to edit task items. Essentially there are few differences to Windows Mobile 5.0 in the look and feel and layout of start menu and applications. One interesting change is that the alarm can now be set to operate only on weekdays, or every day. It's still not as flexible as other approaches, and the default sound applied to the alarm is rather alarming to say the least!

With my initial success I then tried docking the device with my main Vista machine. On this machine I'm running the latest Windows Mobile Device Center 6.1. When I connected the S620 popped up a message telling me to upgrade to ActiveSync 4.5 or later on my PC. Fellow MVP Jaap van Ekris was able to point out a simple workaround. Just go to Start > Settings > Connections > USB to PC and uncheck "Enable advanced network functionality". It now partners correctly with my Vista machine.

Among the Configuration providers in Windows Mobile is one which allows you to programmatically uninstall package from the device. The UnInstall provider is documented here:-

http://msdn2.microsoft.com/en-us/library/aa455977.aspx

To see if your package can be uninstalled you send the following XML - e.g. using DMProcessConfig.XML or ProcessConfiguration in managed code.

<wap-provisioningdoc>
   <characteristic type="UnInstall">
      <characteristic-query type="YourAppName"/>
   </characteristic>
</wap-provisioningdoc>

Replacing YourAppName with the name of your installation package usually "CompanyName Product" as defined in your device CAB project. The response will look something like this if the package name is found:-

<wap-provisioningdoc>
   <characteristic type="UnInstall">
      <characteristic type="YourAppName">
         <parm name="uninstall" value="0"/>
      </characteristic>
   </characteristic>
</wap-provisioningdoc>

Then you can uninstall the package using:-

<wap-provisioningdoc>
   <characteristic type="UnInstall">
      <characteristic type="YourAppName">
         <parm name="uninstall" value="1"/>   
      </characteristic>
   </characteristic>
</wap-provisioningdoc>

In March I showed how to get the version of a connected device from the desktop. This post documents the rest of the registry settings used to store device information. There are two registry locations, the first at HKEY_CURRENT_USER\Software\Microsoft\Windows CE Services contains information about the currently connected device. The second, HKEY_CURRENT_USER\Software\Microsoft\Windows CE Services\Partners contains information for each of the partnerships established on the desktop PC.

When the device is docked, regardless of whether a partnership is established, the following keys are populated in HKEY_CURRENT_USER\Software\Microsoft\Windows CE Services:-

• DeviceHardwareId -String containing a unique Guid for the device
• DeviceOemInfo - OEM specific string (as returned by SystemParametersInfo using SPI_GETOEMINFO) e.g. WIZA200 (HTC Wizard)
• DeviceProcessorType - DWORD value - 2577 (ARM) for all Windows Mobile devices
• DeviceType - string containing platform type (as returned by SystemParamtersInfo using SPI_GETPLATFORMTYPE) e.g. PocketPC or SmartPhone
• DeviceVersion - DWORD value - see my previous post.

The partnerships are stored with a unique DWORD partnership id e.g.

HKEY_CURRENT_USER\Software\Microsoft\Windows CE Services\Partners\12345678\

There are additional values to describe sync behaviour and some Windows Mobile Device Center specific values e.g. to specify the display icon for a device. Otherwise all of the above values are duplicated here for the partner device, except with some naming differences:-

• DeviceHardwareId
• OemInfo
• ProcessorType
• DeviceType
• Version

Each partnership has a directory containing any resources used, this includes the icon etc. The path is retrieved from the DataFolder value. This is a path beneath the users roaming application data folder which you would get using System.Environment.GetFolder(System.Environment.SpecialFolder.ApplicationData)

The icon is specified in DeviceIconFile and if you append this to the path you'll have the full filename of the icon.

Every version of POOM (Pocket Outlook Object Model) brings great improvements, however there are always a few things which just have you screaming "Why!". One of those examples is the implementation of IItem::Edit. This method is used to open an item in edit mode, and is implemented on Windows Mobile 5.0 and above, with the exception of Appointments on Smartphone (Standard) devices. This makes no sense because otherwise the Appointment item follows the same pattern as the other item types. A dialog is implemented on the Smartphone/Standard platform and this has a perfectly usable edit screen - why this wasn't implemented in the API beggars belief. Below is a table of supported configurations for the various display methods:-

*WM5.0 Smartphone Tasks application doesn't support editing

One of the features of Mobile In The Hand is the ability to add context menu extension handlers for the PIM applications from managed code. One of the problems with implementing this feature is that the behaviour of these applications varies subtly between versions and these differences are rarely documented from the developers perspective.

One of these issues is the way that context menu extensions work with regard to multiple item selection. In Windows Mobile 2003 the Tasks and Contacts applications allow the user to select multiple items on Pocket PC using the stylus. When the context menu extension is called you can get the Oids of all the items selected. However in Windows Mobile 5.0 the Contacts user interface was changed and no longer supports multiple selection, but Tasks still behaves as before (Tasks has always been the neglected application of Pocket Outlook - just look at how limited Tasks was on Smartphones prior to Windows Mobile 6 Standard). However if you select multiple tasks on Windows Mobile 5.0 or 6 the context menu will only get the Oid of the first item. You therefore need to set your (and your users) expectations when using Context Menus within your solutions.

On a traditional Standard (nee Smartphone) device the start-menu items are arranged into a 3x3 grid, you can navigate these quickly using the numeric keypad. On a landscape device the items are arranged in a 4x2 grid so this is impractical. Instead the QWERTY keys are used, or to be exact:-

Another helpful feature which was introduced in one of the AKU updates to Windows Mobile 5.0 was a scrollbar so that scrolling off of the current page of menu items would advance to the next or previous screen of items (Equivalent to pressing soft-key "More" or Back button). The scrollbar give you a visual indication of where you are within the menu items which typically span 5 screens in landscape orientation.

One part of the shell which has not received the same attention is the Settings screens. Unlike the Start Menu there is no scrollbar, you must advance to the next screen using the last list item (this is not offered as a soft-key item). This means that in landscape orientation only 6 settings items fit on a page. A few changes here would allow more items per screen and consistency with the start menu behaviour. On devices with a built in scroller such as the HTC S620, T-Mobile Dash etc you could quickly scroll through all the configuration items.

Another place where this behaviour is not followed is the Pictures & Video application. Here the items are again arranged in a 4x2 grid on a landscape device however the key assignments are really wacky:-

You can see that the application is hard-coded to use the numerical keys and so there isn't a shortcut to select the righthand column.

These help to illustrate another area where developing for multiple screen sizes and layouts can introduce complications. You should try to follow best practices to offer appropriate shortcut keys in your application, just be aware that even Microsoft have missed some of these issues in the platform itself.

The Windows Mobile 6 SDK Refresh is available today. It includes some documentation enhancements and new samples. One of these is called RingtoneManager and is a C# application which wraps all the Sound APIs for ringtone management and sound playback, the latter of which were introduced with Windows Mobile 6. This is great because it gives you all the P/Invokes etc you need to use this functionality yourself. However expect to see these Windows Mobile specific APIs in the next version of Mobile In The Hand.

Over on the Windows Mobile Developer Wiki is a topic listing all the APIs and technologies which are deprecated in Windows Mobile 6. This is essential reading for any Windows Mobile developer:

http://channel9.msdn.com/wiki/default.aspx/MobileDeveloper.DeprecatedFeaturesInWindowsMobile6

Thankfully after the previous false-start the Windows Mobile 6 SDKs are now back online and here to stay.

In the last post, I looked at new properties in the Microsoft.WindowsMobile.Status namespace. It turns out that there are some minor improvements in the Microsoft.WindowsMobile.Forms namespace too. The ChooseContactDialog gets a few new properties:-

• FilterRequiredProperties - When true only contacts with the properties specified for RequiredProperties will be shown. This was default behaviour in Windows Mobile 5.0
  
• EnableGlobalAddressListLookup - When true allows the user to also search the GAL (if available)
  
• IncrementalFilter - Contains the text of the filter box at the top of the dialog.
  
• NoUI - No UI is shown at all (Not sure exactly why you'd want to do this...).
  
• NoUIOnSingleOrNoMatch - If only a single outcome is possible the ShowDialog method returns immediately without prompting the user.

Windows Mobile devices, both Smartphone and Pocket PC support Speakerphone functionality. When operating through the Phone application the end user can toggle the state, up until now there has been no documented way to achieve this through code. Last year I investigated the issue on behalf of one of my readers and failed on several attempts at simulating a press-and-hold of the green phone button. It turns out that the device issues a specific key constant to change the state, and this can be simulated through code. It also turns out that the constant is equivalent to VK_F16 (thats Keys.F16 for managed code). I've wrapped up the necessary P/Invoke into the following code:-

public sealed class SpeakerPhone
{
private SpeakerPhone() { }

/// <summary>
/// Toggles the SpeakerPhone state.
/// </summary>
public static void Toggle()
{
//keydown
NativeMethods.keybd_event((byte)Keys.F16, 0, 0, 0);
//keyup
NativeMethods.keybd_event((byte)Keys.F16, 0, NativeMethods.KEYEVENTF_KEYUP, 0);
}

internal static class NativeMethods
{
internal const int KEYEVENTF_KEYUP = 0x0002;


[System.Runtime.InteropServices.DllImport("coredll.dll")]
internal static extern void keybd_event(byte bVk, byte bScan, int dwFlags, int dwExtraInfo);
}
}

Since this just toggles the state, you can't determine the current state at any particular time. This code has been tested on Windows Mobile 5.0 and beyond (It possibly works on Windows Mobile 2003 but I haven't tested), it doesn't work on the Windows Mobile 5.0 Emulators as Speakerphone isn't implemented. I was able to establish a call on speakerphone using the following code:

Microsoft.WindowsMobile.Telephony.Phone p = new Microsoft.WindowsMobile.Telephony.Phone();
p.Talk("01234567890");
SpeakerPhone.Toggle();

Once the call is ended the speakerphone state is restored on subsequent calls.

The Windows Mobile 5.0 SDKs shipped with a number of emulator images, and additional form factors were made available in separate packages at a later date when they were introduced with AKU2. Below is the list of emulator images which will ship with the Windows Mobile 6 SDK:-

Windows Mobile 6 Standard

• Windows Mobile 6 Standard (176x220)
• Windows Mobile 6 Standard Landscape QVGA (320x240)
• Windows Mobile 6 Standard QVGA (240x320)

Windows Mobile 6 Professional

• Windows Mobile 6 Classic (No Phone) (240x320)
• Windows Mobile 6 Professional (240x320)
• Windows Mobile 6 Professional Square (240x240)
• Windows Mobile 6 Professional Square QVGA (320x320)
• Windows Mobile 6 Professional Square VGA (480x480)
• Windows Mobile 6 Professional VGA (480x640)

Except for the square form-factors all of the Professional emulator images support screen rotation, the emulator rotates the device skin in place so that the screen is always shown in the correct orientation on the development computer.

Turns out the SDKs haven't been abducted by aliens, James Pratt reveals the story here on the Windows Mobile blog. So if you missed them you'll have to wait until 1st March for their official release.

The good news is that there will be an update to the SDKs due out on May 1st with new emulator images, additional samples and documentation improvements. Lets hope that all my bug reports submitted on documentation errors in the current release are resolved in that release.

When I previously posted the list of additional system properties I was using the Windows Mobile 6 SDK Documentation as a reference. Well it turns out that there are even more new properties, you can view them using Object Browser in your project but they aren't included in the documentation. The other new properties are:-

• CameraEnabled - This in addition to existing CameraPresent property
• CellularSystemAvailable1xrtt
• CellularSystemAvailableEdge
• CellularSystemAvailableEvdo
• CellularSystemAvailableEvdv
• CellularSystemAvailableGprs
• CellularSystemAvailableHsdpa
• CellularSystemAvailableUmts
• CellularSystemConnected1xrtt
• CellularSystemConnectedEdge
• CellularSystemConnectedEvdo
• CellularSystemConnectedEvdv
• CellularSystemConnectedGprs
• CellularSystemConnectedHsdpa
• CellularSystemConnectedUmts
• ClamshellClosed
• DeviceLocked
• KeyLocked
• LockStates - A combination of flags for Device, Key and Sim locks
• SimLocked
• PhoneTalkingCallStartTime

At first glance it doesn't appear there are any new goodies in the managed code libraries for Windows Mobile 6. But wait, there are - SystemState has gained a few new properties which allow you to monitor the state of:-

• BluetoothStateA2DPConnected
• BluetoothStateDiscoverable
• BluetoothStateHandsFreeAudio
• BluetoothStateHandsFreeControl
• BluetoothStateHardwarePresent
• BluetoothStatePowerOn

and

• WiFiStateConnected
• WiFiStateConnecting
• WiFiStateHardwarePresent
• WiFiStateNetworksAvailable
• WiFiStatePowerOn

Another noticable enhancement, which isn't really part of the managed APIs, is that the dialog for Task items (Task.ShowDialog()) is now much more useful on Smartphone (sorry Standard Edition) in that it has an Edit option with the ability to set properties such as Priority, Status, Reminder etc. These have always been present in Pocket PC (oops Professional Edition) and sorely lacking from Smartphone prior to WM6.

Following Daniel's post announcing the appearance of the Windows Mobile 6 SDKs on Microsoft's download site, I headed off to get the SDKs and start poking around. A common question I can see arising is how to detect if you are running on WM6 from your managed code. The answer is to use the System.Environment.OSVersion.Version property. If your device is running WM6 this will report back 5.2 (for the emulators the full build is 5.2.318 but the build numbers are likely to change by the time real devices emerge). In contrast WM5.0 devices report back 5.1 (5.1.1700 for the original 5.0 SDK emulators). Both platforms are running on top of Windows CE 5.0, and not Windows Embedded CE 6.0 which is currently available, and understandably this can cause some confusion when the OS and marketing versions don't exactly tie up. The .1 and .2 minor versions are special Windows CE releases for Windows Mobile which are not available to generic CE platform builders. You may remember a similar thing occuring with Windows Mobile 2003 Second Edition which had an OS version of 4.21.

You've probably not managed to miss the barrage of reports announcing the upcoming Windows Mobile 6. One in particular caught my eye which was by Loke Uei on new developer features:-

http://blogs.msdn.com/lokeuei/archive/2007/02/07/windows-mobile-6-what-s-in-it-for-developers.aspx

On the device the main highlights are the latest framework and SQL Server CE components in ROM, and two new APIs:-

A couple of days after Vista's official release we now have the final version of Windows Mobile Device Center. This news comes hot off the press from Josh at Windows Connected. If you are running the Beta release grab yourself the final version here:-

http://www.microsoft.com/downloads/details.aspx?FamilyID=83d513ea-9df9-4920-af33-3a0e2e4e7beb&DisplayLang=en

While there have been some improvements to Bluetooth support through the version - like the addition of A2DP (Wireless Stereo) and most recently PAN in AKU3, at the same time the Dial Up Networking profile has been removed. This is a very widely supported profile for connectivity sharing. If you previously used your Windows Mobile device to share your GPRS connection you'll no longer be able to do this with newer devices running AKU3 (or perhaps if any OEMs offer ROM updates to AKU3 for current devices). One scenario I've already encountered where this is a problem is using a TomTom ONE/Go unit - these use Bluetooth to use your phones connectivity to download traffic updates etc, and they support only the DUN profile.

Read a discussion about these changes here on Smartphone Thoughts.

First things first a disclaimer, the following code is written for Mobile In The Hand (Professional Edition), it does apply equally to a Windows Mobile 5.0 project with the Microsoft.WindowsMobile managed APIs, you'll just need to change the namespaces and assembly references.

A normal MessageInterceptor is valid only for the lifetime of your application, once you shut down you'll no longer be able to respond to messages that match your rule. In many cases you'll want a specific message to launch your application and then process as normal. The IApplicationLauncher interface which MessageInterceptor implements contains methods to set this up. This allows the system to start your application, optionally with command line arguments of your choosing. This is useful so that you can tell when your app was called by an incoming SMS and when launched manually. The following code snippet is called in Form_Load, it checks for an existing registration, if not present it sets up all the required settings. The ApplicationLaunchId is a string which is unique to your application, if you try to register with an id which is already in use you'll receive an Exception.

if (InTheHand.WindowsMobile.PocketOutlook.MessageInterception.MessageInterceptor.IsApplicationLauncherEnabled("testapp"))
{
    mi = new InTheHand.WindowsMobile.PocketOutlook.MessageInterception.MessageInterceptor("testapp");
}
else
{
    mi = new InTheHand.WindowsMobile.PocketOutlook.MessageInterception.MessageInterceptor(InTheHand.WindowsMobile.PocketOutlook.MessageInterception.InterceptionAction.NotifyAndDelete);
    mi.MessageCondition = new InTheHand.WindowsMobile.PocketOutlook.MessageInterception.MessageCondition(InTheHand.WindowsMobile.PocketOutlook.MessageInterception.MessageProperty.Body, InTheHand.WindowsMobile.PocketOutlook.MessageInterception.MessagePropertyComparisonType.StartsWith, "test:", false);

    mi.EnableApplicationLauncher("testapp","\\Program Files\\InterceptorTest\\InterceptorTest.exe");
}

mi.MessageReceived += new InTheHand.WindowsMobile.PocketOutlook.MessageInterception.MessageInterceptorEventHandler(mi_MessageReceived);

Finally the event handler just displays the message body in a MessageBox:-

void mi_MessageReceived(object sender, InTheHand.WindowsMobile.PocketOutlook.MessageInterception.MessageInterceptorEventArgs e)
{
    MessageBox.Show(((InTheHand.WindowsMobile.PocketOutlook.SmsMessage)e.Message).Body, "Message");
}

If you refer to the original Windows Mobile 5.0 documentation (or the Intellisense) when using this component you'll notice it has a property called LockDirectory which is supposed to prevent the user from browsing outside of the folder you specified in InitialDirectory. To cut a long story short this property is not implemented and setting it will not affect the behaviour of the dialog. The online MSDN documentation has since been updated to indicate this.

When faced with this problem my first thought was to look at the native API which this component uses (GetOpenFileNameEx) and P/Invoke it since the documentation still indicates that there is a flag to achieve this behaviour. However as it turns out this too is unimplemented. It was a late change in Windows Mobile 5.0 and hence the SDK and documentation were innacurate.

The Windows Mobile 5.0 Pocket PC SDK includes a C# sample application to P/Invoke into the new GPS API in Windows Mobile 5.0. However there are a couple of bugs in the code which make it awkward to work with. One is a simple divide-by-zero which is easily fixed, the other relates to the fact that there was a bug in the RTM build in the way the latitude and longitude were formatted in the RTM release of the platform. Luckily it was patched before any shipping device was released but it affects the original emulators shipped with the SDK. The documentation states that the latitude/longitude are in decimal degrees, but in the RTM release it actually contained the raw NMEA format. The following are the code replacements you should make to get the GPS sample working on your device.

DegreesMinutesSeconds.cs

public double ToDecimalDegrees()
{
  if (degrees == 0)
  {
    return 0.0;
  }

  int absDegrees = Math.Abs(degrees);

  double val = (double)absDegrees + ((double)minutes / 60.0) + ((double)seconds / 3600.0);

  return val * (absDegrees / degrees);
}

GpsPosition.cs

Full details on configuring your device to use GPS are here in Jason's blog post.

Among the fairly modest enhancements to the Microsoft Bluetooth stack in Windows Mobile 5.0 is a new unified system for assigning virtual COM ports. Previously this was only exposed to the user via OEM provided plugins. Very often you were limited to a single incoming and outgoing port. The Pairing process on Windows Mobile 5.0 now does a service discovery and allows the user to choose which services they wish to use, when "Serial Port" is ticked in the list you can then use the new interface on the "COM Ports" tab to create a virtual COM port for the device.

All of the settings are stored in the registry so that you can also programmatically query what ports are setup and to which devices they map. The magic happens at:

HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Bluetooth\Serial\Ports

This key contains a multi-string value containing all of the available COM ports on the system. This should have been setup by the OEM so that it does not contain reserved COM port identifiers. For example on my iMate K-Jam this value contains:-

COM6

COM7

Below this key there will be a key for each device setup with a virtual COM port, the key will be named with an 8 byte hexadecimal device id (16 characters). This contains values with settings for the port such as Encryption etc. The most useful is "Port", a string value containing the COM port name e.g. "COM6". Each device can have only one virtual COM port assigned, so if you run through the "New Outgoing Port" sequence for the same device it will overwrite your previous settings. The pairing information for the device is stored in a similarly named key under:-

HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Bluetooth\Device

You can query the values under the device key (again 16 chars for the device id) to retrieve the device name and class of device. When you retrieve paired devices with 32feet.net using BluetoothClient.DiscoverDevices it reads this information for you into a BluetoothDeviceInfo instance.

This new mechanism means that rather than using the awkward RegisterDevice method for registering a virtual COM port (InTheHand.IO.Ports.BluetoothSerialPort in 32feet.net) you can configure the settings through the registry in such a way that they are visible to device user and don't conflict with other ports.

If you really need to disable the touch screen on a device, there is a method available, but you'll need to soft-reset the device to restore the functionality. You can call the TouchPanelDisable API, it's not documented in the Windows Mobile SDKs but you'll find it in the CE documentation, declaration is very simple:-

<System.Runtime.InteropServices.DllImport("touch")> _
Private Shared Sub TouchPanelDisable()
End Sub

or

[DllImport("touch")]

private static extern void TouchPanelDisable();

There is a possibility that the dll in which this function appears may be different on some devices, so you'll need to do some experimentation first.

When Orange released their AKU 2.0 ROM for the C600 it introduced a much tighter security policy. A previous loophole for changing security policies involving a signed registry editing application was closed by black-listing the app. Also the online unlocking page from the Orange Developer program doesn't recognise a C600 IMEI. Luckily there is a process in place to get your device unlocked for development and testing. Here are the steps to take, you'll get up and running in a day or two:-

Send an email to developers [at] orange [dot] com

Make sure you include all the following information:-

• IMEI of the phone exactly as displayed when you dial *#06# (17 digits long)
• Your full name
• Your orange network country
• Phone number for the handset (must be an orange number)
• Full model number of the device

Using this information they prepare a special unlocking app specific to your device, you should get this back within a couple of days. They will send you this as a zip file with an executable which will run on your desktop and install the component to your device over ActiveSync. On your Smartphone you can then run the tool from Start > Accessories > Security Levels. You can then change the security model to Disabled, Low or High at any time. Turn the phone off and on again for the change to take full effect.

This recent article discussed one of the ways you can use XML provisioning data - through a cab file installation. You can also pass the XML to DMProcessConfigXML or ConfigurationManager.ProcessConfiguration in the managed world. But how about creating the XML?

Well you could use notepad and code it all by hand as a worst-case-scenario. The next best thing is to use the XML support in Visual Studio which will at least help to ensure you write valid XML. Mobile In The Hand 2.0 takes this one step further by adding a schema into VS2005 to ensure your document conforms to the msprov schema:-

1. Create a new XML document in your project

2. With the document selected locate "Schemas" in the properties pane.

3. Click "..." to bring up a list of installed schemas

4. Select msprov from the list

5. Start writing your document and watch the intellisense kick in

The Managed APIs in Windows Mobile 5.0 expose the Contact.WebPage as a Uri. The problem with this approach is that the user forms are free text and you can enter anything into this field. Probably 9 times out of 10 you'll enter an address such as

www.peterfoot.net

And because the managed API passes this to the Uri constructor and it has no http:// prefix it fails and returns null. However there is a solution to workaround the issue. You can access the Properties collection and access the property and it will be returned as a string. So for example you would use:-

[C#]
string webPage = session.Contacts.Items[0].Properties[Microsoft.WindowsMobile.PocketOutlook.ContactProperty.WebPage];

[VB]

Dim webPage As String = session.Contacts.Items(0).Properties(Microsoft.WindowsMobile.PocketOutlook.ContactProperty.WebPage)

If you then want to use a Uri with this value, check to see if it includes the http:// prefix and if not add your own e.g.

Uri contactsWebpage = new Uri("http://" + webPage);

To complement the C# version posted Here,  here is a working VB translation:-

<System.Runtime.InteropServices.DllImport("coredll.dll")> _
Private Shared Function GetDeviceUniqueID(ByVal appdata As Byte(), ByVal cbApplictionData As Integer, ByVal dwDeviceIDVersion As Integer, ByVal deviceIDOuput As Byte(), ByRef pcbDeviceIDOutput As Integer) As Integer
End Function

Private Function GetDeviceId(ByVal appData As String) As Byte()

Dim appDataBytes As Byte() = System.Text.Encoding.ASCII.GetBytes(appData)
Dim outputSize As Integer = 20
Dim output(19) As Byte

Dim result As Integer = GetDeviceUniqueID(appDataBytes, appDataBytes.Length, 1, output, outputSize)

Return output

End Function

A user posted an important observation on the Bluetooth COM support in Windows Mobile 5 here on the microsoft.public.pocketpc.developer newsgroup. The problem is that while the system allows you to create virtual COM ports for all your paired devices which support Serial Port Profile, most of the time this will fail because the COM port you pick is already in use, on many devices you can have just 2 virtual COM ports. I've posted a few of my thoughts in the thread linked above, but while there are things that Microsoft can work to improve there are also a few things that developers can do to avoid the problem:-

• Don't rely on the control panel for setting up ports, use the RegisterDevice route (or BluetoothSerialPort in 32Feet.net) to just register a port for the duration you need it (and possibly reuse the same port name). This also allows you to use a different port prefix since few COMx: ports are available out of the box.
• Don't use serial ports. Unless you need your device to be accessible by a legacy app then you can avoid using virtual COM ports altogether and work directly with Sockets (again 32Feet.net will allow you to setup these connections easily). The downside with this approach is it applies only to the Microsoft Bluetooth Stack, as the programming model for the main alternative from Broadcom is essentially based around ports. However based on the first batch of devices released with Windows Mobile 5.0 the Broadcom stack is a lot less common.

The full build and AKU version of a device is shown on the Start > Settings > System > About screen, however what if you want to determine the version from your code. Well starting with Windows Mobile 5.0 there is now a registry key which holds the AKU version e.g.

RegistryKey kAku = Registry.LocalMachine.OpenSubKey("System\\Versions");

string akuVersion = kAku.GetValue("Aku", "");

kAku.Close();

This version will include a leading period so for example if the string is ".0.1.1" as on the current JasJar ROM the device has AKU 0.1, if it reads ".1.1.0" as on the current K-Jam ROM you have AKU 1.1. As far as I'm aware all shipping devices will have at least 0.1 as some fixes were implemented between RTM in May 2005 and the first shipping devices released later in the year. If your version is ".2.x.x" then you are a very lucky bunny indeed!

Whilst Windows Mobile 2003 had a similar concept of periodic AKU updates throughout it's lifetime this registry key is not available, nor is the AKU version displayed on the About dialog, only the Build number is displayed.

This bug affects both managed and native developers working with the Windows Mobile 5.0 SDK.

Native

Due to an error in snapi.h the location of the registry key used to indicate if a hardware keyboard is present is incorrect:-

////////////////////////////////////////////////////////////////////////////////
// KeyboardPresent
// Gets a value indicating whether a keyboard is attached and enabled.
#define SN_KEYBOARDPRESENT_ROOT HKEY_LOCAL_MACHINE
#define SN_KEYBOARDPRESENT_PATH TEXT("Software\\Microsoft\\Shell")
#define SN_KEYBOARDPRESENT_VALUE TEXT("HasKeyboard")

The root key for this value should instead be HKEY_CURRENT_USER. Once you use this location you can correctly determine if there is a hardware keyboard (this is the same location as used on WM2003 Second Edition devices such as the HTC Blue Angel).

Managed

The SystemState class also uses the incorrect location to read this value so the property will always return false. The workaround here is to access the registry directly using either the Microsoft.Win32.RegistryKey in .NETCF v2.0 e.g.