Manually run Windows Mobile 5.0 SDK script

Some users may find that after installing the Windows Mobile 5.0 SDKs, although no errors were reported, they just don’t show up in the Visual Studio 2005 create project dialog. The reason for this is that sometimes the install script which runs near the end of setup gets blocked by anti-spyware or anti-virus software sometimes without even prompting the user.

The workaround is quite simple, you just need to locate the script and run it from the command line. Locate the folder where you installed the SDK and the Install_files subfolder. Then run the script passing the full path to the SDK and 0 (to install, if you wanted to manually remove you would pass 1). For example if you installed to the default location you’ll need something like this:-

install_script “C:Program FilesWindows CE Toolswce500Windows Mobile 5.0 Pocket PC SDK” 0

NDoc helper for Microsoft.WindowsCE.Forms

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. (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…

Bluetooth Socket Options on Windows XP

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

Windows XP

Windows CE

#define SO_BTH_AUTHENTICATE 0x80000001  // optlen=sizeof(ULONG), optval = &(ULONG)TRUE/FALSE

#define SO_BTH_AUTHENTICATE                                    0x00000001    // optlen=0, optval ignored

#define SO_BTH_ENCRYPT      0x00000002  // optlen=sizeof(ULONG), optval = &(ULONG)TRUE/FALSE

#define SO_BTH_ENCRYPT                                               0x00000002    // optlen=sizeof(unsigned int), optval = &(unsigned int)TRUE/FALSE

#define SO_BTH_MTU          0x80000007  // optlen=sizeof(ULONG), optval = &mtu


#define SO_BTH_SET_MTU                                                0x00000006    // unconnected only! optlen=sizeof(unsigned int), optval = &mtu

#define SO_BTH_GET_MTU                                               0x00000007    // optlen=sizeof(unsigned int), optval = &mtu

#define SO_BTH_MTU_MAX      0x80000008  // optlen=sizeof(ULONG), optval = &max. mtu


#define SO_BTH_SET_MTU_MAX                                    0x00000008    // unconnected only! optlen=sizeof(unsigned int), optval = &max. mtu

#define SO_BTH_GET_MTU_MAX                                    0x00000009    // bound only! optlen=sizeof(unsigned int), optval = &max. mtu

#define SO_BTH_MTU_MIN      0x8000000a  // optlen=sizeof(ULONG), optval = &min. mtu

#define SO_BTH_SET_MTU_MIN                          0x0000000a    // unconnected only! optlen=sizeof(unsigned int), optval = &min. mtu

#define SO_BTH_GET_MTU_MIN                         0x0000000b    // bound only! optlen=sizeof(unsigned int), optval = &min. mtu

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.

Comparing Windows Mobile APIs

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.

Developing with Virtual Earth

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.

How They Beta Test Mappoint Products

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.