If you publish apps on the old Marketplace for Windows Mobile 6.x you should have received reminders that the service will be discontinued in two weeks. If you have been using our Mobile In The Hand product with a managed code app there are a couple of issues to be aware of. Our libraries contain the following two classes to provide programmatic access to the Marketplace client on Windows Mobile 6.x:-

• InTheHand.Phone.Tasks.MarketplaceDetailTask
• InTheHand.Phone.Tasks.MarketplaceLauncher

If these are called on a device with the Marketplace client installed they will launch the client application however once the service is discontinued no application details will be accessible so this may result in a confusing experience for your users. Consider these classes obsolete as they will no longer be supported and will be removed from the next release.

https://inthehand.uservoice.com/knowledgebase/articles/72785-windows-marketplace-for-mobile-6-x-to-be-discontin

.NET Compact Framework

The Compact Framework provides the capability to start a separate process from your code, and stop it but it doesn’t give you more detailed information about what is running and what components are in use. Windows CE includes the optional ToolHelp component (present in all Windows Mobile versions). The InTheHand.Diagnostics namespace includes a number of classes for working with ToolHelp in a way which matches the full .NET Framework. The ProcessHelper class includes the GetProcesses() static method to return all running processes on the device. Extension methods GetModules() and GetThreads() return ProcessModule and ProcessThread collections for a specific Process.

ProcessModule exposes name, size and version information for an individual module. ProcessThread exposes id, priority and elapsed processor time.

Another way you might want to interrogate a process is to determine the memory usage. For your own process we’ve followed the Windows Phone model and so InTheHand.Phone.Info.DeviceExtendedProperties.ApplicationCurrentMemoryUsage

provides you this useful figure as a strongly-typed property. It is also accessible from the GetValue method as you would on Windows Phone.

Windows Phone

Other than the built in set of tasks you can’t start any other applications or tell if they are running. You do have access to memory statistics though which are accessible from the Microsoft.Phone.Info.DeviceExtendedProperties class. A limitation here is that if you use this method to get the memory statistics your app will automatically get marked as requiring the ID_CAP_IDENTITY_DEVICE capability which it doesn’t actually need for these properties. We built a helper class for two reasons – firstly to remove this requirement and secondly to provide strongly-typed properties as an alternative to the GetValue implementation. On Windows Phone therefore you can use:-

InTheHand.Phone.Info.DeviceExtendedProperties.ApplicationCurrentMemoryUsage

InTheHand.Phone.Info.DeviceExtendedProperties.ApplicationPeakMemoryUsage

and

InTheHand.Phone.Info.DeviceExtendedProperties.DeviceTotalMemory

Mobile In The Hand 7.0

Mobile In The Hand is a suite of components for developing mobile applications across Microsoft’s various mobile and embedded operating systems. It will save you development time and allow you to share more code across different .NET project types.

This is the first in a series of posts about Mobile In The Hand 7.0 which brings a collection of reusable components to the .NET Compact Framework. This latest version is updated to support all versions of Windows Mobile including Windows Embedded Handheld, All versions of Windows Embedded Compact (in it’s various names) from 4.1 to 7.0 and a set of companion libraries offering a subset of the functionality on Windows Phone 7.

When the .NET Framework 4.0 was released it introduced a new namespace – System.Device.Location which provided a range of location features. Subsequently this was used as the model for Windows Phone’s APIs. One major whole in the Windows Phone implementation is that the CivicAddressResolver is not implemented and doesn’t return a result. Mobile In The Hand 7.0 comes to the rescue with a two pronged attack:-

An InTheHand.Device.Location.GeoCoordinateWatcher for the .NET Compact Framework. This uses the GPS Intermediate driver present on all Windows Mobile 5.0 and later devices and available as a system component on Windows CE 6.0 and beyond. This is exposed with a familiar object model which matches that found in .NET 4.0 and Silverlight for Windows Phone.

Secondly two new components are provided – BingCivicAddressResolver takes a GeoCoordinate and uses Bing Maps to resolve a CivicAddress object similar to the functionality available on desktop windows. Additionally as an extra feature the BingGeoCoordinateResolver allows you to resolve a GeoCoordinate from an address or partial address. Both of these classes are provided in the .NET Compact Framework and Silverlight for Windows Phone libraries which make up Mobile In The Hand 7.0. The Compact Framework version offers both Synchronous and Asynchronous calls, the Silverlight version just exposes the Asynchronous calls.

This may be a little late to the party but I thought I would share some information on this exam. Because you sign an NDA when you take the exam I cannot comment on specifics of the exam content, however I can offer some guidance on the study guide:-

http://www.microsoft.com/learning/en/us/exam.aspx?ID=70-580

This exam replaced the previous 070-540 exam which covered application development using Windows Mobile 5.0, .NET Compact Framework 2.0 and Visual Studio 2005. Therefore a large percentage of the material is the same between the two. The new topics come in the form of Widgets, LINQ, ADO.NET Sync Services and Windows Mobile Tools such as FakeGPS. The full list of skills measured can be read on the exam link above. There are a couple of oddities:–

• The material is updated for .NETCF 3.5 by including LINQ but WCF is not listed.
• ADO.NET Sync Services has never really been a core part of the development tools.
• Finally one of the skills measured is creating a desktop installer for your application. There is not standard way of doing this but the guidance does exist (see list below) to put together a dll which acts as a custom install action within your desktop installer.

So once you’ve familiarised yourself with all the skills measured you’ll skip to the next tab on Preparation Materials and find there is nothing at all listed. Here is a list I think will help with your preparation:-

Microsoft Mobile Development Handbook – Microsoft Press. While the main book covers .NETCF 2.0 and Visual Studio 2005, the last chapter gives a run down on new features in Visual Studio 2008 and .NETCF 3.5 including LINQ. It ticks almost all of the Skills measured, there are a few articles which cover the new topics:-

Developing Widgets for Windows Mobile 6.5 – MSDN. The Windows Mobile 6.5.3 SDK added some support for Widget development to Visual Studio 2008 but I find it just hangs Visual Studio. This article shows the “old” approach from creating the HTML, JavaScript and building the ZIP file and renaming.

Programming Microsoft Synchronization Services for ADO.NET (Devices) – MSDN. Andy’s article describes Synchronization services from setting up and running synchronization through to optimisations for mobile use.

Using the FakeGPS Utility – MSDN.

The 70-580 exam is quite new and it is quite clear that if and when there is an exam created for Windows Phone 7 development it will by necessity be completely different. However for now 70-580 is the most up-to-date Microsoft exam for Mobility and is one of the requirements for the Mobility competency within the Microsoft Partner Program. Currently it doesn’t appear that there are any exams at all for Silverlight, but there are some coming in the next few months for .NET 4.0 and WPF.

If you want to learn about configuring Exchange Server for mobile devices there is an interactive configuration guide which will work through the actions required depending on your platform and your specific requirements:-

http://wmexchangesetup.com/launcher.aspx

While this week has very much been focussed on Windows Phone 7 so far we also released the latest version of our Mobile In The Hand suite for the .NET Compact Framework. Along with some bug-fixes (several around EmailMessage functionality) and performance improvements there are a lot of new features in this release. These include:-

• Compatibility – We have gone through the entire library and documented which platform versions support which features in a similar way to the MSDN documentation for the underlying APIs. We have also added in more platform checks and workarounds so we are now able to support a much wider range of devices. Pocket PC 2003, Windows Mobile 5.0, Windows Mobile 6, Windows Mobile 6.1, Windows Mobile 6.5, Windows Mobile 6.5.3, Windows CE.NET 4.1, Windows CE 5.0, Windows Embedded CE 6, you get the idea! Basically any device which supports .NET Compact Framework 2.0 or later will be able to use most of the functionality in the suite.
• Better support for .NETCF 3.5 – By adding IEnumerable<T> interfaces to our collection classes you can write slightly simpler LINQ statements. Also we have implemented many features as Extension Methods. These can be used in either .NETCF 2.0 or 3.5 so long as you are using Visual Studio 2008 (The compiler in VS2005 doesn’t support these so you have to call them as static methods).
• New InTheHand.Device.Location.dll library – This is modelled on the .NET 4.0 library and just this week it has been shown that Windows Phone 7 gets a version of the same library. By adding this support we’ve been able to completely re-design our GPS support and you can now write code with the same familiar object model on Windows 7, Windows Phone 7 and Windows Mobile and Windows Embedded CE. In the Evaluation version this shipped as InTheHand.Device.dll but for the full release we changed it to InTheHand.Device.Location.dll to match the Windows Phone 7 name, the namespaces and classes within the assembly are unchanged.
• New InTheHand.Net.dll library – Previously this was released as a separate product but this now joins the suite and has had a number of new features including asynchronous versions of the WebClient methods, support for SMTP email sending, Remote Access (RAS) and some more classes in the NetworkInformation namespace. By integrating with the suite we have been able to share more functionality so for example our Visual Basic “My” extensions now have additional networking methods that are present in the full .NET framework.
• InTheHand.WindowsMobile.Forms.ControlHelper.EnableVisualStyles – This extension method allows you to reskin all the supported controls on Windows Mobile 6.5.3 with their new themed versions.
• InTheHand.WindowsMobile.Forms.Widget – On Windows Mobile 6.5 and later you can interrogate the widgets installed on the device. You can programmatically launch or uninstall Widgets too. There is a new sample application which shows a simple widget manager application.

For more information about Mobile In The Hand see the product page.

http://www.microsoft.com/downloads/details.aspx?FamilyID=c0213f68-2e01-4e5c-a8b2-35e081dcf1ca&displaylang=en

This Developer Tool Kit acts as an add-on to the Windows Mobile 6 SDK. It adds in Windows Mobile 6.5 and 6.5.3 samples, APIs and Emulators. The download link includes separate Professional and Standard Edition packages along with a number of localised emulator images.

There are a number of scenarios in which you want to retrieve the icon associated with a particular executable or other file type. One example is when building a file browser, you might also want to extract the icon associated with your application or another. The full .NET framework contains Icon.ExtractAssociatedIcon() for this very purpose. Mobile In The Hand includes a helper function to achieve the same result from the Compact Framework. Simply use the following code:-

filePath is the full path to any file. The icon will either be the icon associated with a particular file type or in the case of executables will be the embedded application icon (or a generic application icon if not present). The result is a regular System.Drawing.Icon type which you can draw using the Graphics class normally.

The documentation for the IconHelper class is available in the online library. For more information about Mobile In The Hand see the product page.

There have been rumours floating around all over the web about Windows Phone future versions. Microsoft have remained tight lipped allowing various tech sites to come up with all sorts of fanciful stories. However a tantalising news snippet has appeared on Microsoft's website for MIX10 the conference for designers and developers coming up in March in Las Vegas:-

http://live.visitmix.com/News/Windows-Phone-at-MIX10

It will definitely be worth keeping an eye on this event, hopefully more information will be released as the sessions and schedule are firmed up:-

http://live.visitmix.com/Sessions#/tags/WindowsPhone

Microsoft have now released some replacement developer certificates for Windows Mobile. See this post for details and a download link:-

http://windowsteamblog.com/blogs/wmdev/archive/2010/01/12/new-windows-mobile-developer-certificates.aspx

As some of you may have noticed the development certificates which are shipped with the Windows Mobile 6 SDK all expired on 31st December 2009. There have been no updates provided yet so the only official workaround is to fiddle with the date on your development PC and devices to set it before 31/12/2009. A ray of hope has been cast by moderator "Chunsheng Tang" on the MSDN forums:-

"FYI. The issue will be addressed in the next SDK update in the near furture. Besides the workarounds mentioned in this thread, you can also temporarily change the date of the development PC and the devices backward (make sure it's before 12/31/2009)."

One of the new items introduced in version 4.0 is a wrapper for the Email configuration provider. This provides a one-stop-shop to access and modify email account settings. This is used for all email account types except for Exchange synchronisation. Each account is identified by a unique Guid so to work with account settings you'll need to know this. This is exposed through a property of the EmailAccount object, for example the following code loops through all available EmailAccounts for which there is a unique ID (excludes the Exchange account).

foreach       (EmailAccount ea in os.EmailAccounts)

{

   if (ea.Properties[AccountProperty.UniqueStoreID] != null)

The UniqueStoreID is a Guid property and so can be cast to the Guid type (the Properties collection returns items of type object because it caters for all different types of properties).

Guid g = (Guid)ea.Properties[AccountProperty.UniqueStoreID];

The EmailAccountConfiguration class is located in InTheHand.WindowsMobile.Configuration.dll in the InTheHand.WindowsMobile.Configuration.Providers namespace. A new instance is created by passing the Guid into the constructor:-

InTheHand.WindowsMobile.Configuration.Providers.EmailAccountConfiguration eac = new InTheHand.WindowsMobile.Configuration.Providers.EmailAccountConfiguration(g);

Once created you have access to a number of properties which describe the account, you can change any of these and push your changes by calling the Update() method. Properties available include the incoming and outgoing servers, the ServiceType - either "POP3" or "IMAP4", DownloadDays (number of past days to download) and many more. The documentation for the class is available in the online library. For more information about Mobile In The Hand see the product page.

In Mobile In The Hand 4.0 all the Windows Mobile networking features are found in the InTheHand.WindowsMobile.Net assembly. This contains support for Connection Manager, Internet Sharing and Wireless Manager. This post will look at the Internet Sharing classes. Internet Sharing was introduced in Windows Mobile 5.0 AKU 3 but is generally associated with Windows Mobile 6. You can share an internet connection over a USB connection or over Bluetooth using the PAN (Personal Area Network) profile. To enable or disable a sharing session from your code you need only call a single method which looks like this:-

InTheHand.WindowsMobile.Net.InternetSharing.Enable(InTheHand.WindowsMobile.Net.SharingConnection.Bluetooth,"O2")

The first argument is a member of the SharingConnection enumeration which contains values for Bluetooth and Usb. The second argument is the name of the internet connection to use - this is the name of the GPRS connection which will be dialled. A simple Disable method exists to shut down the sharing connection:-

InTheHand.WindowsMobile.Net.InternetSharing.Disable()

You must remember to disable the connection once you have finished using it.

A full online library of class documentation for all this and more is available. For more information about Mobile In The Hand see the product page.

In the last post on "My" functionality I showed you how to get started adding the My Extensions to your project. In this post I have assembled a detailed tree of all the "My" functionality added in Mobile In The Hand 4.0.

• My
  • Application
    • Culture
    • Info
      • AssemblyName
      • CompanyName
      • Copyright
      • Description
      • DirectoryPath
      • ProductName
      • Title
      • Trademark
      • Version
    • UICulture
  • Computer
    • Audio
      • Play()
      • PlaySystemSound()
      • Stop()
    • Clipboard
      • Clear()
      • GetData()
      • GetDataObject()
      • GetImage()
      • GetText()
      • SetData()
      • SetDataObject()
      • SetImage()
      • SetText()
    • Clock
      • GmtTime
      • LocalTime
      • TickCount
    • FileSystem
      • CombinePath()
      • CopyDirectory()
      • CopyFile()
      • CreateDirectory()
      • DeleteDirectory()
      • DeleteFile()
      • Drives
      • FileExists()
      • GetDirectories()
      • GetDirectoryInfo()
      • GetDriveInfo()
      • GetFileInfo()
      • GetFiles()
      • GetName()
      • GetParentPath()
      • GetTempFileName()
      • MoveDirectory()
      • MoveFile()
      • OpenTextFileReader()
      • OpenTextFileWriter()
      • ReadAllBytes()
      • ReadAllText()
      • RenameDirectory()
      • RenameFile()
      • SpecialDirectories
        • CurrentUserApplicationData
        • MyDocuments
        • ProgramFiles
        • Programs
        • Temp
      • WriteAllBytes()
      • WriteAllText()
    • Info
      • AvailablePhysicalMemory
      • AvailableVirtualMemory
      • InstalledUICulture
      • OSPlatform
      • OSVersion
      • TotalPhysicalMemory
      • TotalVirtualMemory
    • Keyboard
      • SendKeys()
    • Name
    • Ports
      • OpenSerialPort()
      • SerialPortNames
    • Registry
      • ClassesRoot
      • CurrentUser
      • GetValue()
      • LocalMachine
      • SetValue()
    • Screen
  • User
    • Name

A full online library of class documentation for all this and more is available. For more information about Mobile In The Hand see the product page.

One of the goals of the Mobile In The Hand library has always been to provide a consistent managed API regardless of which specific flavour of Windows Mobile device you are using. One example of this is using the Vibration feature used to alert the user. The APIs are completely different and so we have provided a simple managed API composing of just two static methods:-

InTheHand.WindowsMobile.Forms.Vibrate.Play();

System.Threading.Thread.Sleep(500);

InTheHand.WindowsMobile.Forms.Vibrate.Stop();

You generally won't want to vibrate the device for very long because it would be both annoying, and a battery drain. To avoid holding up your UI thread you can call the methods on a separate thread. Just remember you must call Stop() to turn off the vibration.

Another example of functionality which is implemented differently between touchscreen and non-touchscreen devices are Profiles. Standard Edition devices can feature a number of profiles for different scenarios, touch screen devices have just three - On, Vibrate only and Off. To retrieve all of the available profiles use the following code:-

foreach(string profile in InTheHand.WindowsMobile.Forms.MobileDevice.Profiles)

{

MessageBox.Show(profile);

}

You can set the device profile using a call to SetProfile:-

InTheHand.WindowsMobile.Forms.MobileDevice.SetProfile("Vibrate");

The name of the currently selected profile is available from the CurrentProfile property:-

MessageBox.Show(InTheHand.WindowsMobile.Forms.MobileDevice.CurrentProfile);

A full online library of class documentation for all this and more is available. For more information about Mobile In The Hand see the product page.

A commonly requested feature is the ability to switch audio to play through a Bluetooth headset device. Mobile In The Hand 4.0 brings this functionality to .NET Compact Framework developers allowing you to play any device audio through a paired headset device. It also includes classes to playback sounds too.

The AudioGateway sample application which ships with the library contains the functionality to playback a sound file and toggle between the device speaker and a headset. The code to perform the switch is incredibly simple:-

private   BluetoothAudioGateway bag = new BluetoothAudioGateway();

The BluetoothAudioGateway exists in the InTheHand.WindowsMobile.Media namespace. A CheckBox control toggles the output using the following code:-

private   void chkGateway_CheckStateChanged(object sender, EventArgs e)

{

   if (chkGateway.Checked)

   {

      bag.OpenAudio();

   }

   else

In the last post we saw the new My Extensions template which adds access to new Visual Basic features. In this post we will look at another new item introduced with Mobile In The Hand 4.0 - Provisioning XML. Visual Studio has a rich XML Editor built in, Windows Mobile uses provisioning XML documents for everything from adding a browser favourite through to configuring a new GPRS network. The new template allows you to quickly create an empty Provisioning XML document and includes the schema to ensure your document is valid. Let Visual Studio's Intellisense help you quickly build a provisioning document.

As with the Visual Basic example you start with an existing device project, in this case it can be either C# or Visual Basic. Select Add New Item and choose Provisioning XML from the list:-

In this example I have called the file AddFavourite.xml (no prizes for guessing what task we will be performing). The document is created with a skeleton provisioning document. Notice the namespace is provided which links to the schema we installed for you.

You can now add the required code between the wap-provisioningdoc tags. As you start to type the IntelliSense will suggest valid elements for you based on the schema:-

This makes it very easy to quickly build up a complete document:-

You can process a configuration document like this using the ConfigurationManager class. By setting the document as an embedded resource you can use the following code to load it and pass it to the ConfigurationManager:-

Dim xd As New System.Xml.XmlDocument

xd.Load(System.Reflection.Assembly.GetExecutingAssembly().GetManifestResourceStream("VisualBasicDeviceProject.AddFavourite.xml"))

InTheHand.WindowsMobile.Configuration.ConfigurationManager.ProcessConfiguration(xd, False)

After running this code you can check your Internet Explorer Mobile favourites:-

For more information about the library see the product page.

This blog post will walk through the process of adding the additional "My" functionality added in InTheHand.VisualBasic. To start off, open Visual Studio 2008 and create a new Visual Basic device project (or open an existing one). At this point you'll end up with a solution window which looks a bit like this. Note the inspired project name in this example:-

The next step is to right-click the project and select Add > New Item... from the menu:-

This will bring up the Add New Item window from which you should see MyExtensions among the list. Select this (you can change the default name if required) and click Add.

The new code file is added to the project. You don't need to edit this and you won't be interacting with it directly from your code. Your solution window will now look like this:-

You can now get on with building your application. Any time you start to type My you'll see a much longer list of options:-

Application, Computer and User are new items added by this library and provide additional functionality, all remaining a direct subset of the desktop experience. For example I added a button and in the Click handler added this simple code snippet:-

MessageBox.Show(

My.Application.Info.ProductName)

On running the code the Product Name is retrieved from the assembly information:-

In a future post I'll run through the various items available through the "My" syntax. For more information about the library see the product page.

Today we put the final touches to Mobile In The Hand 4.0 and have released this latest version of the suite. This is a major reworking of the code and the library is now broken into 10 separate dlls so you only need to deploy the specific functionality you require in a project. We have also added some additional functionality alongside the code libraries themselves to add "My" keyword functionality for Visual Basic users and make it easier to incorporate and edit provisioning XML documents. Over the next few weeks I'll be posting a number of blog articles to highlight new features and elaborate on some of the less visible features.

Full details of the library are available on the product page.

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.

Luis Cabrera has posted the details of a bug identified in the Talk method to the Windows Mobile Team blog. The workaround (see the original post) is to append a null character to the end of your dial string.

Note: this bug doesn't affect InTheHand.WindowsMobile.Telephony.Phone.Talk.

The ItemId type is introduced to the managed APIs to represent either a POOM Oid (int) or MAPI ENTRYID (16/14 bytes). It doesn’t directly expose the underlying data but there are a couple of useful behaviours:-

• ItemId constructor accepts an int to create an ItemId from an existing known Oid value
• For POOM items (Appointment, Contact, Task) calling GetHashCode() on the ItemId returns the underlying Oid. However since this behaviour is not specifically documented it cannot be relied upon to stay this way in a future version.
• Oids on Windows Mobile 5.0 are created differently to previous versions. On older platforms the Oid is the identifier of the CEDB database record containing the item. On Windows Mobile 5.0 the databases are housed in an EDB database. Here the POOM Oid is a separate field containing a unique id and the item type, therefore it's possible to infer the type from an Oid unlike previous versions - 0x4000001 would be an Appointment, 0x80000001 a Contact and 0xC0000001 a Task.

Windows Mobile 5.0 introduces a managed API which wraps both POOM and a subset of CEMAPI (enough to send an Email / Sms). The table below is designed to show how the managed objects map to the interfaces which will be familiar to seasoned POOM developers. It also shows those parts of POOM which are not available through the managed APIs:-

Here is another issue I've been banging my head against a brick wall with and the workaround - although it's not a pleasant workaround by any measure.

To read the body text of an email message under WM2003 you open the PR_BODY property of the message and this gets you the plain text body of the message, no headers, no fancy encoding - just the facts! However in Windows Mobile 5 this now returns an empty stream. So how do we get at the body of the message, the Messaging application certainly knows how to. Well the answer from Microsoft is that although this change in behaviour is not documented you must now change your approach. Instead you need to access the PR_CE_MIME_TEXT property (defined in cemapi.h). This contains the entire message, header and all, and may require you to deal with mime encoded body. My first impression of this is that it's a backwards step which unnecessarily breaks existing code, you'd expect the API to deal with the underlying implementation and decoding and have the properties such as PR_BODY exposed to the outside world. Ah well, progress I guess...

When you want to create a meeting request with managed POOM on WM5.0 you start by creating an Appointment and then add Recipient objects to it's Recipients collection. However what the documentation doesn't tell you is that you have to ensure that your Recipient has both the Name and Address properties. For example:-

Microsoft.WindowsMobile.PocketOutlook.Appointment ma = new Microsoft.WindowsMobile.PocketOutlook.Appointment();
ma.Subject = "Test 5";
ma.Recipients.Add(new Microsoft.WindowsMobile.PocketOutlook.Recipient("user@yourdomain.com"));

Will throw a Win32Exception with the text "Native method call failed". This isn't very descriptive but the reason it fails is due to how native POOM works - the IRecipients.Add method takes a name argument and since your Name property is empty this call fails. If you specify the name e.g.

ma.Recipients.Add(new Microsoft.WindowsMobile.PocketOutlook.Recipient("User","user@yourdomain.com"));

or even this if you only have an address:-

ma.Recipients.Add(new Microsoft.WindowsMobile.PocketOutlook.Recipient("user@yourdomain.com","user@yourdomain.com"));

Then you'll be okay.

Some great news from Jason Langridge - not only will AKU 2 introduce the long awaited messaging feature pack, but also introduce the A2DP (Advanced Audio Distribution Profile) Bluetooth profile to support mono and stereo audio devices such as headphones and some advanced car kits. ETA is early 2006 depending on individual OEM schedules for ROM updates.

Mark has posted the final version of his MSDN article on designing for stylus-free usage on Windows Mobile. This covers both what you get for free in .NETCF v2.0 for navigating around forms with the d-pad and also what you can do to make some of the other intrinsic controls behave. Mark's sample code includes wrappers around these "badly behaved" controls such as the DateTimePicker.

I like John Kennedy's proposed SDK TOC for Windows Mobile. And since the sample contains valid links, I was surpised at the amount of content I found which I'd not been able to locate before

While there will always be cases when organising content like this you could end up in heated debates about whether article x belongs in category y or z, I believe it's a definate improvement and gives better visibility of the scope and content of the SDK documentation. I particularly like the fact that Whats New is the first category with itemised details for each update - the SDK documentation has already received two batches of updates.

Update: I've realised there isn't any Telephony content on this contents page. It would be good to have an entry for Telephony (which is an important part of most Windows Mobile devices) and it should link through to TAPI, Phone, SMS and SIM topics.

There has been a lot of activity recently on new Windows Mobile 5.0 devices, in a few cases official announcments, in some cases details leaked through common sources such as the FCC site where products sent for testing are publically detailed.

One of the interesting models to be revealed has been discussed by WallabyFan, with the original scoop at the register. The unique feature of this device is that it is the first Windows Mobile Smartphone to feature a built in GPS. The feature has previously been available on a small number of Pocket PC devices, most recently in the iPaq 65xx range.

HTC are busy with Pocket PC devices in the form of the Universal, and the Wizard - successor to the Magician (iMate JAM and equivalents), and also new Smartphone models such as the Tornado - a WiFi equipped Smartphone.

All in all it looks like a lot of exciting new devices will bring Windows Mobile 5.0 to the market place.

As has already been shown with some of the other libraries in WindowsMobile In The Hand, the object model is generally designed to follow the Windows Mobile 5.0 APIs. There are a few examples where new functionality is exposed which is not found in the WM 5.0 APIs, some of which was designed specifically to complement Windows Mobile 5.0.

In the case of the Forms assembly, none of the WM5.0 forms are supported, this is because functionality such as CameraCaptureDialog and SelectPicture dialog rely on new functionality in the underlying OS - prior to WM 5.0 each OEM implemented their own camera support.

However in WindowsMobile In The Hand, a few new pieces of forms related functionality are added:-

The MessageBox is designed to provide a softkey-enabled message box for Windows Mobile 5.0 Pocket PCs (although it can also be used on prior versions). When used in a Smartphone project it uses the standard compact framework implementation, on a Windows Mobile 5.0 Pocket PC it produces the following:-

It's been designed to follow the Smartphone experience so you can provide the same user experience on both platforms. It supports a full range of overrides for the Show method to specify buttons, icon etc. Here the MessageBoxIcon is used to draw a watermark image on the dialog, similar in spirit to the themed icons which are used on the Smartphone equivalent.

MobileDevice provides a few helper methods to reset the device, and get the platform type identifier e.g. PocketPC or Smartphone.

MobileKeys provides a mapping between the device specific key constants (as defined in winuserm.h) and the desktop key codes, so all of the members are of type System.Windows.Forms.Keys.

OpenFileDialog is built specifically for Windows Mobile 5.0 Smartphone and matches the System.Windows.Forms version available in Pocket PC projects. Again if used in a Pocket PC project it utilises the existing implementation in System.Windows.Forms. It will currently raise a NotSupportedException if used on a Smartphone 2003 device.

This applies equally to WindowsMobile In The Hand and the Windows Mobile 5.0 APIs. On the collection classes there exists a Restrict method which returns a subset of the collection matching your search query. You can use the resulting collection to databind or otherwise enumerate over.

The query language used is similar, but not the same, as SQL: if you imagine that what you are entering here is just the WHERE clause of a query you will not be far off. The key rules to follow are:-

• Field names must match exactly - refer to the Properties of the Appointment, Contact and Task class for valid field names
• Field names must be enclosed in square brackets e.g. [MobileTelephoneNumber]
• You can combine multiple expressions with AND and OR
• Supported operators are < (Less Than), <= (Less Than or Equal To), > (Greater Than), >= Greater Than or Equal To), = (Equals), <> (Not Equals)
• Items without the property set will not be returned in a query. So if you set a query of [BusinessAddressCity] = "London" it would not return items without the business address city present even though these are not London.
• You can use this knowledge to form a query to return all records where the property is set with [PropertyName] <> "" as all items with the property set will match this pattern.

You can return a full contact list for all items with a mobile number using this code:-

os = new OutlookSession();

PimItemCollection pic = os.Contacts.Items.Restrict("[MobileTelephoneNumber] <> \"\"");

listBox1.DataSource = pic;

listBox1.DisplayMember = "FileAs"

This example bind the collection to a control, the list will show the contact name only but you'll be able to retrieve the Contact object from the SelectedItem property of the list box to use it's other properties (e.g. the mobile number).

For Windows Mobile 5.0 you can use the new ChooseContactDialog which features a RequiredProperties property so you can easily setup the dialog to show only relevant items.

Update: Here is the VB equivalent:-

os = New OutlookSession
Dim pic As PimItemCollection = os.Contacts.Items.Restrict("[MobileTelephoneNumber] <> " & Chr(34) & Chr(34))
ListBox1.DataSource = pic
ListBox1.DisplayMember = "FileAs"

Some users may find that after installing the Windows Mobile 5.0 SDKs, although no errors were reported, they just don't show up in the Visual Studio 2005 create project dialog. The reason for this is that sometimes the install script which runs near the end of setup gets blocked by anti-spyware or anti-virus software sometimes without even prompting the user.

The workaround is quite simple, you just need to locate the script and run it from the command line. Locate the folder where you installed the SDK and the Install_files subfolder. Then run the script passing the full path to the SDK and 0 (to install, if you wanted to manually remove you would pass 1). For example if you installed to the default location you'll need something like this:-

install_script "C:\Program Files\Windows CE Tools\wce500\Windows Mobile 5.0 Pocket PC SDK\" 0

To illustrate how the WindowsMobile In The Hand is a subset of the Windows Mobile 5.0 APIs I've modified this class diagram for the Windows Mobile 5.0 APIs to ghost out those which are not supported in WindowsMobile In The Hand on earlier devices. The key differences are in support for system state events and in the number of properties supported - there is no easy way to do events for these system properties without a lot of polling which is bad. Also it lacks many new properties on the PIM items (such as Photos for contacts) including the ability to add custom properties - this is based on a lot of work on the underlying POOM APIs which would not be feasable to replicate on older devices.

wm5vwmith1.jpg (679.87 KB)

In a future post we will look at what is added beyond the standard Windows Mobile 5.0 APIs.

Earlier I posted to the newsgroup a description of using Alex Feinman's Tapi Wrapper to retrieve the IMEI of the phone device. When I checked again, the specific required method is not included in the wrapper, however as Alex has made the line handles accessible it's easy to tag functionality onto the library without re-inventing the wheel. I put together a VB example to P/Invoke the lineGetGeneralInfo method to retrieve information about the phone device. If you use this on a Smartphone device you may find it doesn't work - this is because many Smartphone devices require signing to access many of the TAPI methods. I tested this on a HTC Phone Edition device

TapiVBExample.zip (52.74 KB)

Personally I like the new icons based start menu in Windows Mobile 5.0 Smartphone, however some people have asked if it's possible to revert to the old list view. The answer is yes, via a simple registry tweak. For this I'm using the Remote Registry Editor from VS2005. Locate the key

HKEY_CURRENT_USER\Software\Microsoft\Shell\StartMenu

Change the value "GridView" from 1 to 0. The change takes effect immediately when you next open the start menu. As with the large icons view the full 9 items are listed with the more option mapped to the left softkey. This always bugged me with SP2003 especially when a menu had 9 items with the 9th requiring a whole new page. You can change the value back to 1 for the new WM5 experience.

During his session at MEDC, Robert Levy handed out copies of a cool class library diagram for the new Windows Mobile 5.0 managed APIs, thanks to Robert for allowing me to post the diagram here - simply print to a large sheet of paper and enjoy :)

WM5APIs.gif (242.62 KB)

The much anticipated update to Windows Mobile has been announced by Bill Gates this morning. This new platform will be the first platform from Microsoft to include device specific managed APIs in ROM (separate from the .NET Compact Framework itself). These allow access to configuration, telephony, pocket outlook etc from managed code.

But what about existing devices? To add to our existing PocketOutlook library we have produced a WindowsMobile suite which includes a large proportion of WindowsMobile 5.0 APIs for previous versions. More details are available here.

As well as supporting older generations of Windows Mobile, the suite also supports Windows Mobile 5.0, and one library in particular InTheHand.WindowsMobile.Gps provides a managed wrapper around the native GPS API in Windows Mobile 5.0

In due time the PocketOutlook library v1.7 will be released with an object model more closely aligned to Windows Mobile 5.0 APIs.

Media Player 10 is the first device version to have an automation model. Previous versions could be controlled via some undocumented windows messages but that was about it. The Media Player 10 Mobile object model is COM based, so you can't use it directly from .NETCF v1.0. I set about creating a wrapper months ago but it got left due to lack of time. However I've decided there is enough functionality available in it now for it to function. I've not had time to create a sample application, so your challenge if you choose to accept it (and I'll be honest there isn't a prize!) is to create something using the assembly.

Because theres no support for hooking com events with a sink interface the wrapper exposes no events, also because there isn't ActiveX hosting support you won't get any UI - so this is useful for audio content only. The other big limitation is that you must have Media Player 10 on your device.

Other than that feel free to have a play and see what fun you can have with it, any issues suggestions or cool creations you build with it please drop me an email or post a comment.

Download InTheHand.MediaPlayer.zip

The built in applications in Pocket PC follow a familiar model with a DocumentList screen listing files of that type, and then an "editor" screen for working with an individual document. If you launch a specific document programmatically it will open direct to that document, but when you close the app will continue to run returning to the document list. You can add the "-opendoc" argument to launch the application for that specific document and close completely once you've finished working with it. This allows you to more seamlessly use these applications from your own code and determine when they have completed. Using the Process class you would do:-

Process p = Process.Start("pword.exe","-opendoc \"\\My Documents\\mypocketwordfile.pwd\");

This argument is supported by Notes, Pocket Word, Pocket Excel and Pocket Streets