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.

From Jason Langridge: "It's using the Microsoft Bluetooth stack".

Excellent, another device added to the growing list.

The Bluetooth.NET library has now reached it's v1.5 milestone and is now part of the 32feet.NET suite. It joins an updated version of my IrDA library for the desktop which now adds some features (borrowed from the Bluetooth developments) so provides a superset of IrDA functionality on either full or compact frameworks. On top of both these libraries sits Object Exchange, this new library makes it easy to programmatically send and receive files and objects over the Object Exchange (OBEX) protocol. This is designed to provide a similar experience to functionality available for .NET for conducting HTTP requests - ObexWebRequest and ObexListener.

The concept of 32feet.NET is to look at personal area networking for the .NET developer whether your platform of choice is .NETCF on Windows CE or full framework on XP, Tablet PC, XP Embedded or Vista (32 Feet is the range of a standard Bluetooth device, that's 10 metres if you prefer metric). The website has been setup with discussion forums for the current libraries and associated technologies, you'll also find all the class library documentation, and of course the download itself which contains assemblies, source, help documentation and samples.

A request came up on the newsgroups for just the dlls for the SDF. This could be useful if you are using the VS2005 Beta. Of course if you don't know why you need these or what to do with them, then you can safely ignore this message and grab the package from http://www.opennetcf.org/download.asp?product=SmartDeviceFramework14

[Via MP2KMag.com]

At PDC on Tuesday (13th) Microsoft will unveil a new collection of APIs for it's MSN services to be available from http://msdn.microsoft.com/msn, these will include:-

• MSN Search Web Services
• MSN Messenger Activity API (already available here)
• MSN Virtual Earth API

The last item is interesting. Firstly it sounds like this will be a "proper" documented API, rather than the jscript hacks currently available. Secondly it is being offered free for both commercial and non-commercial use. It is interesting therefore to see how it stacks up against it's big brother Mappoint Web Service for simple commercial applications.

Speaking of which, the new version of Mappoint Web Service (4.0) will also be released at PDC. New features include support for polygons, some new map styles, and further extensions to the mapping coverage.

[Update] MWS 4.0 SDK is available:-

http://www.microsoft.com/downloads/details.aspx?FamilyID=cb5148a9-f09e-4ec8-992f-16478c0b5d9a&DisplayLang=en

The session submissions are all in and it's now your chance to vote for those you want to attend. So pick your top 20 here:-

http://www.developerday.co.uk/ddd/votesessions.asp

Also Sarah has setup a Wiki page to organise a Geek Dinner in Reading after the event, if you are interested in attending check out Sarah's blog post, and sign up on the Wiki.

Earlier in the Beta for Visual Studio 2005 I submitted a product suggestion to support a very common scenario with the MessageWindow control, and I was delighted to find that in the July CTP it has been implemented.

The MessageWindow class is provided as a mechanism to receive incoming windows messages and has become a key part of the .NETCF developers interoperability toolbox. .NETCF v2.0 extends the options we have available with new functionality such as support for passing callback functions into native code and COM interop. However there are still times when we will need the humble MessageWindow. One of the first tasks with using the MessageWindow is how to tell the sender where to send the messages. In some cases this involves passing the handle (HWND) of the MessageWindow in via a P/Invoke call, the other common way to identify a MessageWindow is by setting the text and using FindWindow.

This neatly brings me back to the new feature in question. In v1.0 you had to override the WndProc and add your own handler for WM_GETTEXT (and optionally WM_SETTEXT) in order for your MessageWindow to have a caption. .NETCF v2.0 adds the Text property making life that little bit easier. Just set the Text property to something uniquely identifiable for your application, then you can use FindWindow from your native code to get the handle (HWND) of the MessageWindow and start sending messages to it.

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.

In order to determine all the known issues with .NETCF v1.0 and which Service Pack contained the fix, you would need to look through the fix list for each of the Service Packs in turn. For ease of reference I copied the three fix lists from SP1,2 and 3 and categorised them into the following table. The "o"s indicated in which service pack the issued was resolved. Below it is a table showing which version is preinstalled on the various Windows Mobile devices which have had .NETCF in ROM.

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.

Neither .NETCF v1.0 or v2.0 will support runtime hosting, this means it's not possible to write a service in managed code which will run within the Services.exe process. However it is often useful to be able to query and manipulate other system services from managed code.

An example of this is where a system service needs to be stopped so that you can access some hardware - such as the OBEX listener service on Windows Mobile which opens the Infrared port. With this scenario in mind I set about wrapping some of the CE functionality for managing services, using the desktop framework as a model.

The resultant library - InTheHand.ServiceProcess.dll is designed as a subset of System.ServiceProcess.dll - this is the assembly which is added as a reference to your project when you create a windows service project with the desktop framework. The library includes a single class ServiceController which is created with the identifier of the service you which to attach to. Under Windows CE these services have an identifier in the form of a device name e.g. AAAN: where AAA is the prefix, often providing a clue as to the purpose of the service, and N is a numerical index. Returning to our example of OBEX the service is called OBX0:. If you don't know the name of a particular service you can either trawl through the registry under HKLM\Services, or better still call the ServiceController.GetServices static method. The final consideration is to ensure you close/dispose the ServiceController when you have finished working with it. Our OBEX shutdown code looks like this:-

ServiceController scObex = new ServiceController("OBX0:");
scObex.Stop();

while(scObex.Status!=ServiceControllerStatus.Stopped)
{
    System.Threading.Thread.Sleep(1000);
}

scObex.Close();

Notice that the WaitForStatus method isn't supported so in this case we periodically check the status while sleeping. If we weren't bothered when the service shutdown you could leave out this section, even when you call Close() to close our handle to the service it will continue with it's action and shutdown in it's  own time.

In terms of platform support, this services.exe model is supported on CE.NET 4.x and above so this includes Windows Mobile 2003 and above.

You can download the library here:-

http://www.inthehand.com/Services.aspx

Greg Scott from the Windows CE Networking team has posted an interesting article on how Bluetooth Virtual COM ports are implemented on Windows CE.

Alongside the native code to setup a port, there are some details on the improvements in Windows Mobile 5.0 which now includes UI options to set both incoming and outgoing ports and is integrated into the bonding/pairing process. This means that OEMs no longer need to produce their own individual applets to expose this functionality.

For managed code the Bluetooth.NET library wraps this functionality with the BluetoothSerialPort class.