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

I posted this to the newsgroup earlier, but figured it was a useful thing to post for future reference. If you want to implement a custom IMessageFilter using OpenNETCF.Windows.Forms.ApplicationEx you have to be aware that VB.NET autogenerates a main proceedure for you if your project startup object is a form. Therefore it will use the Application.Run method and your filter will never be used. Instead you can implement a Sub Main as your startup object and use ApplicationEx:-

Public Shared Sub Main()

ApplicationEx.Run(New MyFormType())

End Sub

Then set your Startup object in project properties to your new Sub Main rather than the name of your form class.

The agenda for DDD Day II has now been published and for some crazy reason folks voted for my Bluetooth with .NET session I'll be covering both the Bluetooth and Object Exchange components of the 32feet.NET suite, I wont touch on the IrDA part, but the code would be almost exactly the same. We'll walk through discovery, client and server connections and sending/receiving objects, hopefully with some audience participation.

It's a great priviledge to be selected along with such a great selection of excellent speakers so I have a lot to live up to! I now have to attempt to make my demonstration application absolutely bullet proof since it inexplicably failed when I gave a short session at the MVP Summit. But it wasn't my code at fault honestly, it worked fine during lunch afterwards (I had several witnesses), obviously a result of the the sinister EM radiation around the Redmond campus...

I was asked how to replace the default Toshiba stack installed on the M200 with the Windows stack (to allow for .NET programmability). Luckily it's easy to do and Toshiba include the necessary bits on the hard disk.

First you need to uninstall the Toshiba stack - Go to Add/Remove programs and select "Bluetooth Stack for Windows by Toshiba"

Next run the C:\TOSHIBA\MS_Bluetooth\BtMon2Inst.exe installer to install the BT monitor.

Finally reboot the machine, the system will detect the radio and install the necessary drivers.