The Bluetooth functionality (and related APIs) are fundamentally unchanged between XP and Vista, however additional profile support has been added for Audio devices. Based on testing with the RC2 build Vista now supports:-

• Handsfree
• Headset
• A2DP (Wireless Stereo)

When Vista detects a new audio device it doesn't automatically install support for the audio services, but it does recognise hands free devices based on their Class-of-Device:-

If you select the device properties, and view the Services tag you can see and select the supported audio profiles and when you apply the settings a new Audio device will be installed.

You can set these programmatically using 32feet.NET with the BluetoothDeviceInfo.SetServiceState method passing in either BluetoothService.Headset or Handsfree. The audio device appears in the Sounds control panel applet, but doesn't override the default system audio. You are unlikely to want to do this with a headset anyway, although it's more likely you'll want to do this with stereo headphones. You can however select this audio device to use with audio conferencing software such as Skype or Windows Messenger or with Vista's speech recognition.

I recently ran into a problem with a Smart Device CAB Project in Visual Studio 2005, which as it turns out is a known issue. You can build a CAB file which will register your .NETCF dlls into the GAC - the File System Editor has a standard folder called "Global Assembly Cache Folder" which you can put your files into. Behind the scenes this deploys the dlls to the windows folder and generates a .GAC text file with a list of paths to your dll(s). The problem is that the generated GAC file is a Unicode text file and doesn't work on devices prior to Windows Mobile 5.0. I'm assuming the same is true with generic CE 4.2 devices versus CE 5.0. In itself this seems bizarre since CE is fully Unicode based so shouldn't have any problem reading the file. It just so happens that when you are doing this the old fashioned way with notepad you get an ANSI text file which works just fine on all devices.

The workaround is simple, don't use the whizzy GAC support in the CAB project, place your dlls into the Windows Folder, and manually create a .GAC text file and place this in the Windows Folder also. The downside to this approach is that you must update your GAC file if you add or remove dlls from your setup project. I'd like to say thanks to fellow MVP Jan Yeh for helping to test the issue and to Manish Vasani from the Visual Studio for Devices team for following up with more details on the issue.

Recently I tried a different form of Bluetooth hacking, I purchased a simple car kit and wanted to install it myself. Alongside the kit itself I also purchased the required vehicle specific cable to sit between the vehicle wiring and the radio and connect in the Parrot loom. However I soon realised that it was going to be more difficult than originally anticipated because there wasn't enough space behind the dash to accomodate all the bulky connectors, relaybox and oceans of cables. There were two issues, the adaptor cable passed through every single cable from the vehicle connector even though only a select few were actually used, the inline ISO connectors are rather chunky, the radio itself supports a phone input and mute trigger and so it seemed unnecessary to have the parrot amplify the audio and output it directly to the speakers.

So I set about looking at what was happening before the relay box and was able to determine the pinouts on the Parrot unit itself. The next stage was to simplify the adapter cable to remove unnecessary passthrough wires and remove the inline ISO connectors. I had to directly solder in Power, Earth and Mute wires from the Parrot and connect up the mono phone input to the "raw" output from the Parrot. The only additional wiring required was vehicle specific as there isn't an ignition switched power into the radio as it uses the CAN bus to change state. So I ran the ignition line for the Parrot into the connector with the vehicles cigar ligher socket (on some cars this is permanently powered on mine it's only on with the ignition). I was then able to mount the Parrot box behind the dashboard and route all the wiring behind the vehicle trim. Using this approach has the added benefit of supporting the external volume adjustment through the radio (and hence steering wheel controls). For reference the pin out for the Parrot CK3000 Evolution is as below (Other Parrot models use rather different plugs so I doubt it's transferrable).

Aud-    Earth   Aud+   Mute

White   Black   Red    Blue   Yellow

 X       X       X      X      X

 X       X       X

Red     Yellow  Blue

(used by control panel)

The unused yellow wire is perhaps used by the optional flashing cable. The separate power connector contains three colour coded wires (which are labelled so I wont spell them out here)

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.

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.