Although it took a lot longer than I originally anticipated I've finally put the finishing touches to v2.0 of the 32feet.NET library. v2.0 is a major re-write of the code so that the single codebase can be built into separate dlls for desktop or device. This was primarily to get around the bug in the desktop VB.NET compiler which couldn't cope with redirecting the device System.dll reference to the desktop equivalent. It has had the pleasant side-effect of making the footprint much smaller. The 4 previous dlls are now merged into the single InTheHand.Net.Personal.dll which range from 91kb for the .NETCF v1.0 version to 76kb for the desktop v2.0 version.

You can download the installer which includes the library, documentation and samples from the 32feet website. This release is the first release version to have the full source code available since the project was hosted at CodePlex. You can also use the CodePlex site to download other builds of the code and post bugs/feature requests. If you want to get involved in the project drop me a mail, or join the discussions on the 32feet site.

Although many Windows CE devices include the aygshell.dll component which offers some functionality available in the Pocket PC shell, it's not directly taken advantage of by .NETCF. For example, when you add a ContextMenu to a control in a Pocket PC project you automatically get tap-and-hold behaviour on the control. Run the same code on an aygshell equipped CE device and nothing happens. Therefore I wrote the following helper class to allow you to hook up the context menus. Simply call HookAllControls(Me.Controls) from your code (e.g. in your form constructor after the call to InitializeComponent() ) or at any other stage if you are dynamically creating controls on your form. Now when you run your app you'll get the tap and hold circles and your context menu will be displayed. Obviously this only works on CE devices which have aygshell support. Just to mix it up a bit this sample is in VB.NET but you should find it easy to convert to C#.

Namespace InTheHand.Windows.Forms


Public Class ContextMenuHelper


Private Shared mousedelegate As System.Windows.Forms.MouseEventHandler = New System.Windows.Forms.MouseEventHandler(AddressOf ControlMouseDown)

Public Shared Sub HookAllControls(ByVal thecontrols As Control.ControlCollection)

'attach to the mousedown event on all controls with a context menu
For Each thiscontrol As Control In thecontrols

If Not thiscontrol.ContextMenu Is Nothing Then

AddHandler thiscontrol.MouseDown, mousedelegate

End If

HookAllControls(thiscontrol.Controls)
Next

End Sub


Private Shared Sub ControlMouseDown(ByVal sender As Object, ByVal e As System.Windows.Forms.MouseEventArgs)

Dim senderctrl As Control = CType(sender, Control)

'if theres no context menu do nothing
If Not senderctrl.ContextMenu Is Nothing Then

Dim shrgi As New SHRGINFO
shrgi.cbSize = 20
shrgi.hwndClient = senderctrl.Handle
shrgi.dwFlags = 3
shrgi.ptDownx = e.X
shrgi.ptDowny = e.Y
Dim result As Integer = SHRecognizeGesture(shrgi)
If result = 1000 Then

senderctrl.ContextMenu.Show(senderctrl, New System.Drawing.Point(e.X, e.Y))
End If
End If

End Sub

<System.Runtime.InteropServices.DllImport("aygshell.dll")> _
Private Shared Function SHRecognizeGesture(ByRef shrg As SHRGINFO) As Integer
End Function

Public Structure SHRGINFO
Public cbSize As Integer
Public hwndClient As IntPtr
Public ptDownx As Integer
Public ptDowny As Integer
Public dwFlags As Integer
End Structure

End Class

End Namespace

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.

In an amazing about-face, Broadcom have released their Bluetooth SDK (Both the desktop and Windows CE versions) for free on their website, all you need to do is provide some basic information to register and you'll receive a download link via email. In many ways the Broadcom stack has always been ahead of the Microsoft version in terms of supported profiles, the real stopper has been the need to purchase the SDK to develop for it.

Thanks to forum member Robert83 for the heads-up!

It will be interesting to see how this affects the balance of stacks on new devices, now that both have an accessible programming model, however each stack is not without it's faults - lack of radio control for Broadcom and fewer profiles supported by Microsoft for example.

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.

The Bluetooth SIG have introduced a new branding initiative to help clarify what functionality a Bluetooth device supports using a number of simple icons for popular applications of Bluetooth. The current 5 icons are:-

• Print (Hard Copy Replacement Profile, Basic Print Profile)
• Input (Human Input Device Profile)
• Headset (Headset Profile, Handsfree Profile)
• Transfer (Object Push Profile, OBEX FTP)
• Music (Advanced Audio Distribution Profile, Audio Video Remote Control Profile)

Each has specific requirements which must be met for the product to display the icon. It should help to make it possible to identify what functionality a device provides. Windows Mobile 5.0 currently supports the requirements of the Input, Headset and Music icons. It doesn't qualify for Transfer since OBEX FTP is not supported, it is a Windows CE component which is not included in the Windows Mobile platform. And as we know Windows Mobile has no printing support out of the box, however if you have a Bluetooth printer which supports Object Push you can beam Contacts, Appointments and Text/HTML documents to your printer.

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.

For a while the migration path from Pocket Access to SQL CE / SQL Mobile has been missing a key piece of functionality which many Pocket Access applications relied on - the Synchronisation functionality in ActiveSync which synchronised with an Access database on the PC.

Today we have some good news from the SQL Mobile Team - A tool called here "Sync with Access", which is due out in Beta form in August, will return this functionality for SQL Mobile (and the forthcoming SQL Everywhere Edition).

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.

One of the features of the Broadcom stack is that when you attempt to connect to a virtual COM port it will show the user the Bluetooth Manager and ask them to select a paired device to connect to. You can suppress this and have it always connect to the last used device. You'll need to write to the registry key:-

HKLM/Software/Widcomm/BTConfig/AutoConnect/0008

Create a DWORD value named BTBrowserEnabled and set the value to 0. If you want to re-enable this feature you can reset the value to 1.

There are a number of ways you can make use of Shortcuts within your project. You may create a shortcut to your application during your CAB file installation - either on the Start Menu or perhaps in the \Windows\Startup folder. VS2005 makes this easy because it has a nice file system graphical editor for CAB projects. Another way you can use shortcuts is within your code itself. There are two API functions to support this - SHCreateShortcut and SHGetShortcutTarget. By P/Invoking these from your .NETCF application you can create your own launcher applications which reuse the shortcuts setup for your Start Menu for example.

There are some caveats when using these functions though which you need to be aware of, the documentation has been revised since the Pocket PC 2003 SDK to warn you of this. To understand why let's have a quick look at the contents of an LNK file:-

34#"\My Documents\Templates\Memo.psw"

As you can see it's a very simple text format. The number indicates the length of the path, this is followed by the # symbol then the full path to the target. When the path contains a space it must be wrapped in quotes. So what were those caveats? Well whatever path you pass to SHCreateShortcut it doesn't add these quotes how you would expect - you end up with:-

34#"\My" Documents\Templates\Memo.psw

This path is invalid and the shortcut won't work. The solution is to wrap any path you pass into SHCreateShortcut with quotes to begin with. Even if the path doesn't contain spaces this will give you a valid shortcut.

The second caveat comes with the SHGetShortcutTarget API. When this reads the shortcut file it doesn't strip out the quotes if present, this means your returned path cannot be used as-is with any of the System.IO functionality. The solution to this one is very simple - perform a Trim() on the returned string passing in the " character - this will remove the leading and trailing quotes and leave you with a valid path. If your shortcuts are to executables and also have arguments specified you will need to split the quoted path from any following arguments.

To demonstrate both of these techniques I've attached a sample VB.NET project. It can create and list shortcuts and when you tap on an item it will launch the target document. For a true launcher application there are some additional steps, for example retrieving the Icon for the file, these are not included in this sample.

I've posted a Beta build of 32feet.NET to the Files section of the site. Please read the file description for a high-level list of changes. This release is the first to be built against .NET v2.0 and will resolve issues encountered with using the v1.x library from a .NET v2.0 VB project. It also consolidates the previously separate dlls into a single dll (InTheHand.Net.Personal.dll) which reduces the overall footprint to 83kb for Infrared, Bluetooth, Object Exchange and Forms functionality. If you are at MEDC and would like to see this version in action, Nick Landry will be using it as part of his session on Thursday at 11:15 "APP335 Tablet PCs and Smartphones: Working Hand-in-Hand to Enable Your Mobile Workforce".

I'm partly blogging to show I haven't fallen off the face of the earth (yesterday was a near miss though), and partly to plug MEDC2006 which is starting today in Las Vegas.

Being somewhat of a cheapskate I opted for an indirect flight here, the first leg, a mere 8 hours or so from London to Minneapolis went almost without a hitch (in fact we were early), it was all downhill from there. The second flight loaded up and taxied out towards the runway. We then had a message from the captain to tell us that his pre-flight checks indicated that the plane had no hydraulic fluid at all, which could be a bit of a bugger for steering the plane. Thankfully he decided that it would be a bad idea to try. So we then taxied back to the terminal and piled off the plane. Luckily there was another plane available, although because it was a subtly different flavour of 757 they had to reassign many of the seats. So that makes it my 16th plane in the last 2 months, I think after Vegas I'll have a bit of a break from air travel for a while!

So now although still tired I'm ready and looking forward to the cool stuff this week has to offer. I'll be helping out on the MVP Cabana on Wednesday and Thursday, and hanging out with fellow MVPs and OpenNETCF folk.

This is a post I've been meaning to do for a couple of years and just never got around to it. The table below is an attempt to document the Bluetooth profiles supported on various flavours of Windows. Because Windows CE is modular don't expect every CE device to support all the possible profiles, this table gives an indication of what the platform creators had available to them. In order to conserve space I've made copious use of acronyms (and initialisations), the current release versions of all of these profiles are documented on the public Bluetooth website.

What I haven't attempted to do is compare the profiles available on 3rd Party stacks, that would be a little more complex