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:-

Changes have been made to the DateTime type in v2.0 to help indicate whether a specific value represents a local time or universal time. What this can mean is that the behaviour of web services using DateTimes will change. This article has full details of the issue:-

http://blogs.msdn.com/mattavis/archive/2005/10/11/479782.aspx

The same approach is available under .NETCF v2.0 to request the old v1 behaviour - add a configuration file for your exe with the following content:-

Jason Langridge has recently given an interview to the BBC about an upcoming enhancement to XBox Live which will allow you to send messages from within XBox Live to MSN Messenger users, this is a very interesting feature and it makes a lot of sense to help tie the two systems together.

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.

As the name suggests, Windows Live Local (the new name for MSN Virtual Earth) is now live. It has a fresh new look, mapping data for Europe (woohoo!), supports driving directions, custom pushpins and for a selection of US cities it has high quality "birds-eye" images. There have been some changes to the API in this version, full details of which are due to hit MSDN today.

One of the transparent benefits of building your projects with VS2005 is that the default File Alignment is now set at 512 bytes, rather than the 4096 bytes which was the default for device projects in VS2003. This means if you create a new project in both versions and add exactly the same code you should notice the output dll created by VS2005 is noticably smaller.

One thing you may not realise is that the default value used in a VS2003 project is stored within the C# project file, which means if you import a VS2003 C# Smart Device project to VS2005 it will still use the value 4096. You can change this from the project properties > Build tab > Advanced button and set it to 512.

In the Windows Mobile 5.0 audio gateway implementation there are a couple of control codes to turn on audio routing through the bluetooth headset/handsfree device. I've only tried this with a couple of devices and had mixed (That's a really bad audio pun sorry!) results but here's a library to allow you to try it yourself. In theory it may work on some 2003 Second Edition devices too. I'd be interested to hear your feedback.

To set audio routing just call

InTheHand.Net.Handsfree.AudioGateway.RouteAudioToHandsfree = true;

And set to false to return to normal audio use.

Once fully tested and documented this will make it into the 32Feet package.

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.

I was delighted to hear the results of the Pocket PC Magazine Best Software Awards. This year the SDF has won in both Pocket PC and Smartphone categories. It's great to be involved in such a successful group project. Also I had a personal win with PocketOutlook In The Hand (now part of the WindowsMobile In The Hand suite) winning in the Smartphone .NET Developer Libraries category, along with 4 other entries reaching the Finalist stage.

Kudos to the Pocket Pc Magazine team and judges for organising the awards, it has been good to see the number of developer entries increase since the developer categories were introduced in 2003, and it will be interesting to see how this trend continues next year with Visual Studio 2005 and .NETCF v2.0 in full swing.

A fairly obvious bug managed to go unnoticed in the GetSetting method for about 18 months. The problem is fairly straight-forward - the method will never return a value if one is found (if not present it returns the default value you supply).

I've fixed it for the next version, but what are you options for working around the issue with current code:-

• Use the RegistryKey directly instead - OpenNETCF.Win32.RegistryKey directly matches the .NET v2.0 version so any code you write against this is very portable.
• Use the attached updated OpenNETCF.VisualBasic.dll. However in order for this method to work you will have to manually copy the dll to your program folder, and make sure your reference points to this version of the dll - 1.4.51101 OpenNETCF.VisualBasic.zip (3.61 KB)
• Grab the updated code from the Vault and build the code into your own dll/executable and call that instead of the OpenNETCF.VisualBasic version.

It would be interesting to get some feedback on whether people are actually using this VB specific functionality, and if so how useful you find it, and what else you would like to see in future versions...

You are going to hear this a few hundred times over the next 24 hours, so I may as well add another me too post. Visual Studio 2005 final release is available for download for MSDN subscribers. It's only a matter of days now before it's officially on the shelves.

http://blogs.msdn.com/somasegar/archive/2005/10/27/485665.aspx

First tasks after installing will be to make sure everything which worked on the various builds (My demo laptop is still running July CTP because I got my demo working on that build and was too frightened to break it!) installs and works with the release version. And I think it's going to be a slow download as MSDN downloads are strangely busy this evening So what are the chances it will have finished downloading by the morning?

I really enjoyed DDD Day 2 on Saturday. I hope my session was useful and can help raise some interest in the possibilities (and challenges) provided by using Bluetooth for peer-to-peer networking. My slides are available to download here:-

BluetoothDDD2.ppt (107.5 KB)

Since I'm new to public speaking I'd really appreciate your feedback on the session so that I can improve my technique. There is an online feedback form on the DDD Day 2 website which I encourage all attendees to spend a few moments on.

It was difficult to choose which sessions to pick as there were a few clashes on my must-see list. Also some of the sessions had a limited capacity and required registration, which filled up very quickly. But those other sessions I did catch were very interesting, the Avalon and AJAX sessions were quite inspiring. Many of the other speakers and attendees are posting their thoughts on the event, there are also some photos.

Marcus has posted some instructions on installing .NETCF v2.0 runtimes to a Windows Mobile 5.0 device. Of course you may wish to deploy to Pocket PC 2003 devices too, again it's a RAM install, and you can follow the same basic steps. There are a few points to note:-

• You can still build an Autorun in .NETCF v1.0 code as all Pocket PC 2003 devices will have at least the RTM release of v1.0 in ROM. Autorun on devices with multiple card slots can be flaky this was improved in v5.0
• The CAB file for Pocket PC 2003 is much larger (5.1mb) since Pocket PC 2003 doesn't support compressed CAB files. By default you'll find it here:-

C:\Program Files\Microsoft Visual Studio 8\SmartDevices\SDK\CompactFramework\2.0\v2.0\WindowsCE\wce400\armv4\NETCFv2.ppc.armv4.cab

• The Autorun code will require modification because it relies on managed ConfigurationManager - you can either P/Invoke DMProcessConfigXML or use an available wrapper (if your device is a Phone Edition device) or OpenNETCF Registry wrapper - works for all PPC2003 devices.
• You'll need to modify how the Autorun determines the path of the SD card on which the files are contained. One solution is to check for potential storage cards with this code:-

http://www.opennetcf.org/forums/topic.asp?TOPIC_ID=432

• Place some token file on your SD card and check for it's existence on each returned path, then when you have your SD card folder you can programmatically install the cab file(s). Again I shouldn't need to give you any hints as to where to find a Process class for .NETCF v1.0