If you've tried documenting .NETCF libraries which make use of Compact Framework specific types you'll know that you have to do all sorts of workarounds and special builds to get an output which can successfully run through NDoc. This is because although the device specific assemblies such as Microsoft.WindowsCE.Forms are marked retargetable there isn't an equivalent in the desktop framework to retarget to.

One solution is aggressive conditional compilation to hide all hints of of these device classes. Another way which is cleaner and easier to deal with when you are regularly updating code and documentation is to build your own dummy classes into your NDoc configuration of your project. I've done this for documenting my own code as I often find myself using MessageWindows etc in my projects. Ratherthan everyone re-invent the wheel you can use the file (see link below) as-is. You will still be producing a separate dll for documentation purposes but the amount of code you have to hack around with is greatly reduced.

Simply add the attached cs or vb file to your project. Then when you build the project in Debug or Release configuration absolutely nothing is added into your dll which will reference Microsoft.WindowsCE.Forms normally. But when you do an NDoc build and define the NDOC conditional constant it will magically spring into life and create a local dummy copy of the whole Microsoft.WindowsCE.Forms namespace. Because of the way the compiler chooses which class to reference your local version will take preference over the official library, thus removing all dependency on the Microsoft.WindowsCE.Forms library.

Microsoft.WindowsCE.Forms.zip (1.27 KB)

For this to work in VB there are a couple of additional points, firstly make sure you don't have a Root Namespace configured (Project > Properties). You will also need VBCommenter to build the XML output used to feed Ndoc (Visual Studio 2005 will introduce built in XML comments generation for VB.NET projects).

Of course the same technique can be used for other device specific assemblies such as System.Data.SqlServerCe, although it contains a lot more types and so is less practical to do in this way. You can instead use this technique just with the individual types/methods you use...

Windows XP supports a much smaller number of socket options for Bluetooth than Windows CE, although it generally provides alternative ways to get/set those properties. The table below shows those that are supported on XP and how they relate to their Windows CE equivalent. Notice that the only one which behaves the same on both platforms is SO_BTH_ENCRYPT

The current version of the Bluetooth.NET library doesn't include the XP versions in the BluetoothSocketOptionName enumeration, but I have added these for the next release.

To illustrate how the WindowsMobile In The Hand is a subset of the Windows Mobile 5.0 APIs I've modified this class diagram for the Windows Mobile 5.0 APIs to ghost out those which are not supported in WindowsMobile In The Hand on earlier devices. The key differences are in support for system state events and in the number of properties supported - there is no easy way to do events for these system properties without a lot of polling which is bad. Also it lacks many new properties on the PIM items (such as Photos for contacts) including the ability to add custom properties - this is based on a lot of work on the underlying POOM APIs which would not be feasable to replicate on older devices.

wm5vwmith1.jpg (679.87 KB)

In a future post we will look at what is added beyond the standard Windows Mobile 5.0 APIs.

Casey posted this cool technique of using the Virtual Earth Locator in your own apps. Next task is to find out how to stop it locating me in Surrey :)

Now that the hype has died down on Virtual Earth it is interesting to see what developers are doing with the product even though it doesn't expose any kind of developer API. The best place to start is at Dr Neil's site Via Virtual Earth. There are a few articles here showing how to pull maps from virtual earth onto your own website. To a user outside the US the mapping detail available is a bit lacking, you get quite a selection of place names, but no roads and satellite imagery only at a very high level.

Hopefully the technologies demonstrated in Virtual Earth will permeate through to the Mappoint Web Service, as the dynamic pan and zoom, imagery and pushpin labels are quite impressive.

Ever wondered how Microsoft test their location products? I mean it's not like you can test them in every possible location. Well two guys in Great Britain are trying to come close by driving the length and breadth of Great Britain passing through key points as they go - They have already covered the furthest South, East and West already. You can track their progress on a special blog and win a copy of Autoroute with GPS receiver if you estimate their mileage.

Autoroute 2006 (European version of Streets & Trips) is due out in October, no details of features for the new release have been announced yet.

Today I gave a session at Slide5 on the latest version of the Bluetooth library - v1.4. Key changes for this release were some bug fixes to the samples, increased functionality for the desktop side (ability to bond devices) and service discovery (as yet XP only). I've also tidied up some of the code, in order to have just a single place to determine the platform at runtime. I'll post a version of the OBEX demo I did shortly, but I'll build it as a VS2003 project (the app used for the session demo was built with VS2005 Beta 2)

Downloads

The "Implementing a Proximity Search with SQL 2000" article describes how to create a local method of searching for nearby places on your own locally held data. However it makes a couple of assumptions, one being that you will import your data via Access.

It's quite likely that you may want to put your place data directly into SQL Server, you can then calculate the X, Y and Z co-ordinates using a stored proceedure. Firstly I'll assume you place the data into a table in your SQL database with fieldnames Latitude and Longitude storing the values in decimal degrees as a float type. You'll also need to add columns named XAxis, YAxis and ZAxis to your table, again with a float type. Then the following stored proceedure can be used to populate these fields.

UPDATE [tablename] SET XAxis = cos(RADIANS(Latitude)) * cos(RADIANS(Longitude)),
YAxis = cos(RADIANS(Latitude)) * sin(RADIANS(Longitude)),
ZAxis = sin(RADIANS(Latitude))
WHERE XAxis IS NULL;

Note that the where clause ensures it doesn't process rows you have already populated. You may choose to run this procedure manually when you add new data, or schedule it to run regularly. If your data is editable once it's in the database, you should ensure the X,Y,Z values are removed if the Latitude and Longitude are changed on a record. Once you've run this on your data you can use the FindNearby procedure described in the article.

Earlier I posted to the newsgroup a description of using Alex Feinman's Tapi Wrapper to retrieve the IMEI of the phone device. When I checked again, the specific required method is not included in the wrapper, however as Alex has made the line handles accessible it's easy to tag functionality onto the library without re-inventing the wheel. I put together a VB example to P/Invoke the lineGetGeneralInfo method to retrieve information about the phone device. If you use this on a Smartphone device you may find it doesn't work - this is because many Smartphone devices require signing to access many of the TAPI methods. I tested this on a HTC Phone Edition device

TapiVBExample.zip (52.74 KB)

One of our forum members posted about an open source social networking project which uses the Bluetooth.NET library. The project is created by Software Greenhouse which is a joint venture between Microsoft India and Cynapse.

Their initial prototype release and source code can be downloaded by registering at the Software Greenhouse site. The software will allow users of Windows Mobile devices to compare user profiles to look for shared interests and chat with other users. This is an interesting use of the technology and it will be interesting to see how the project evolves. Have you used the Bluetooth library in any projects? if so please leave a comment.

A requested feature for NETCF is to retrieve a list of named colors. Fortunately this is easily done using reflection to read all the public statis properties of the Color class:-

System.Reflection.PropertyInfo[] colors = typeof(Color).GetProperties(System.Reflection.BindingFlags.Public | System.Reflection.BindingFlags.Static);
Color[] allcolors = new Color[colors.Length];


for(int i = 0; i < colors.Length; i++)
{
    allcolors[i] = (Color)colors[i].GetValue(null,null);
}

comboBox1.DataSource = allcolors;

In this example the full list is assigned to a ComboBox for display purposes.

With the release of the Smart Device Framework v1.3 the compiled help documentation was no longer included in the installer. I've built a standalone installer to install the full collection of documentation into your Visual Studio help. This release includes:-

The full package is approximately 5mb but once installed makes it much quicker to search than using the online version. It installs with either Visual Studio 2003 or Visual Studio 2005 Beta, Download it here.

This is a very basic sample app to assist a thread in the newsgroup. Basically it shows a couple of approaches to working with the Clipboard, both using SDF v1.3.

The first is the TextBoxEx class onto which I've added a ContextMenu with edit commands. The second is a plain TextBox and I've added buttons to call methods on the OpenNETCF.Windows.Forms.Clipboard class.

In .NETCF v2.0 there will be basic functionality on the Clipboard class but it wont have the GetText and SetText shortcut methods. The OpenNETCF.Windows.Forms.Clipboard class follows the desktop v2.0 equivalent so should be fairly intuitive to use.

The sample project was written and tested with a Pocket PC 2003. On brief testing with the 2002 emulator the context menu causes problems due to the way a tap and hold is handled and the control loses focus, thus the selection is removed, therefore no text is cut to the clipboard. I have yet to try on Pocket PC 2000/2002 device so I'd be interested in hearing if there are any problems encountered. It requires SDF v1.3 and I also recommend you are running the latest .NET Service Pack (SP3).

Today I've completed the v1.3 release of Bluetooth. This pulls together the latest binaries, source code, samples and help documentation into a single package. There are few differences in the public interface from previous releases, notably the BluetoothSerialPort class has been fixed and re-introduced, also the BondedDevices property for retrieving previously bonded devices from the registry.

I've also prepared a class-library diagram to accompany this release:-

OpenNETCF.Net.Bluetooth.1.3.50525.png (136.1 KB)

You can download the installation package from here.

With the Microsoft Bluetooth stack a single outbound virtual COM port is supported, to set this up you have to bond with the device. If you want to switch between several devices at different times this is awkward. You can however alter the registry settings between connections to switch devices.

1. Setup an Outbound COM port for the first device

2. Bond with the other device(s) you wish to use

3. Make a note of the bluetooth IDs of these bonded devices - see the subkeys of [HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Bluetooth\Device] for details

4. Before switching devices ensure you do not have the outbound virtual COM port opened (often COM 5 but check on your device).

5. Replace the value of "OBBDaddr" in the key [HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Bluetooth\SerialPort] with the bluetooth address of your required device.

6. Open the COM port - now connects to the device specified in the above registry key.