In The Hand Ltd

Category: Windows Mobile

  • What’s New For Managed Developers In Windows Mobile 6

    At first glance it doesn’t appear there are any new goodies in the managed code libraries for Windows Mobile 6. But wait, there are – SystemState has gained a few new properties which allow you to monitor the state of:-



    • BluetoothStateA2DPConnected

    • BluetoothStateDiscoverable

    • BluetoothStateHandsFreeAudio

    • BluetoothStateHandsFreeControl

    • BluetoothStateHardwarePresent

    • BluetoothStatePowerOn

    and



    • WiFiStateConnected

    • WiFiStateConnecting

    • WiFiStateHardwarePresent

    • WiFiStateNetworksAvailable

    • WiFiStatePowerOn

    Another noticable enhancement, which isn’t really part of the managed APIs, is that the dialog for Task items (Task.ShowDialog()) is now much more useful on Smartphone (sorry Standard Edition) in that it has an Edit option with the ability to set properties such as Priority, Status, Reminder etc. These have always been present in Pocket PC (oops Professional Edition) and sorely lacking from Smartphone prior to WM6.

  • Am I Running on Windows Mobile 6

    Following Daniel’s post announcing the appearance of the Windows Mobile 6 SDKs on Microsoft’s download site, I headed off to get the SDKs and start poking around. A common question I can see arising is how to detect if you are running on WM6 from your managed code. The answer is to use the System.Environment.OSVersion.Version property. If your device is running WM6 this will report back 5.2 (for the emulators the full build is 5.2.318 but the build numbers are likely to change by the time real devices emerge). In contrast WM5.0 devices report back 5.1 (5.1.1700 for the original 5.0 SDK emulators). Both platforms are running on top of Windows CE 5.0, and not Windows Embedded CE 6.0 which is currently available, and understandably this can cause some confusion when the OS and marketing versions don’t exactly tie up. The .1 and .2 minor versions are special Windows CE releases for Windows Mobile which are not available to generic CE platform builders. You may remember a similar thing occuring with Windows Mobile 2003 Second Edition which had an OS version of 4.21.

  • Windows Mobile 6 for Developers

    You’ve probably not managed to miss the barrage of reports announcing the upcoming Windows Mobile 6. One in particular caught my eye which was by Loke Uei on new developer features:-


    http://blogs.msdn.com/lokeuei/archive/2007/02/07/windows-mobile-6-what-s-in-it-for-developers.aspx


    On the device the main highlights are the latest framework and SQL Server CE components in ROM, and two new APIs:-


  • Windows Ink Services Platform (WISP) Lite
  • New Sound API – Plays MP3s and more

    The first came as a bit of a shock, after all in Windows Mobile 5.0 the number of places in the OS where Ink was used was reduced, no more Ink notes on Pocket Outlook items for example. I’ll be interested to see what this API supports.


    The sound functionality will be greeted with cheers by many developers, there are many occasions when you need to simply play a wma or mp3 audio file and there isn’t anything as comfortable to use as PlaySound and yet supporting audio types other than .wav.


    There are a number of improvements to the Emulator tools which are always welcome, especially in the early stages when it will be difficult to get hold of Windows Mobile 6 devices. The last item on the list entitled “Platform unification investments” is rather vague, I look forward to finding out exactly what this means for the end developer. Anything that simplifies writing code once for the multitude of Windows Mobile versions and form factors available gets my full approval!

  • Windows Mobile Device Center Released

    A couple of days after Vista’s official release we now have the final version of Windows Mobile Device Center. This news comes hot off the press from Josh at Windows Connected. If you are running the Beta release grab yourself the final version here:-

     

    http://www.microsoft.com/downloads/details.aspx?FamilyID=83d513ea-9df9-4920-af33-3a0e2e4e7beb&DisplayLang=en

  • Bluetooth DUN Profile Removed from WM5.0 AKU3

    While there have been some improvements to Bluetooth support through the version – like the addition of A2DP (Wireless Stereo) and most recently PAN in AKU3, at the same time the Dial Up Networking profile has been removed. This is a very widely supported profile for connectivity sharing. If you previously used your Windows Mobile device to share your GPRS connection you’ll no longer be able to do this with newer devices running AKU3 (or perhaps if any OEMs offer ROM updates to AKU3 for current devices). One scenario I’ve already encountered where this is a problem is using a TomTom ONE/Go unit – these use Bluetooth to use your phones connectivity to download traffic updates etc, and they support only the DUN profile.


    Read a discussion about these changes here on Smartphone Thoughts.

  • Using MessageInterceptor to launch an application on SMS

    First things first a disclaimer, the following code is written for Mobile In The Hand (Professional Edition), it does apply equally to a Windows Mobile 5.0 project with the Microsoft.WindowsMobile managed APIs, you’ll just need to change the namespaces and assembly references.


    A normal MessageInterceptor is valid only for the lifetime of your application, once you shut down you’ll no longer be able to respond to messages that match your rule. In many cases you’ll want a specific message to launch your application and then process as normal. The IApplicationLauncher interface which MessageInterceptor implements contains methods to set this up. This allows the system to start your application, optionally with command line arguments of your choosing. This is useful so that you can tell when your app was called by an incoming SMS and when launched manually. The following code snippet is called in Form_Load, it checks for an existing registration, if not present it sets up all the required settings. The ApplicationLaunchId is a string which is unique to your application, if you try to register with an id which is already in use you’ll receive an Exception.


    if (InTheHand.WindowsMobile.PocketOutlook.MessageInterception.MessageInterceptor.IsApplicationLauncherEnabled(“testapp”))
    {
        mi = new InTheHand.WindowsMobile.PocketOutlook.MessageInterception.MessageInterceptor(“testapp”);
    }
    else
    {
        mi = new InTheHand.WindowsMobile.PocketOutlook.MessageInterception.MessageInterceptor(InTheHand.WindowsMobile.PocketOutlook.MessageInterception.InterceptionAction.NotifyAndDelete);
        mi.MessageCondition = new InTheHand.WindowsMobile.PocketOutlook.MessageInterception.MessageCondition(InTheHand.WindowsMobile.PocketOutlook.MessageInterception.MessageProperty.Body, InTheHand.WindowsMobile.PocketOutlook.MessageInterception.MessagePropertyComparisonType.StartsWith, “test:”, false);

        mi.EnableApplicationLauncher(“testapp”,“Program FilesInterceptorTestInterceptorTest.exe”);
    }

    mi.MessageReceived += new InTheHand.WindowsMobile.PocketOutlook.MessageInterception.MessageInterceptorEventHandler(mi_MessageReceived);


    Finally the event handler just displays the message body in a MessageBox:-


    void mi_MessageReceived(object sender, InTheHand.WindowsMobile.PocketOutlook.MessageInterception.MessageInterceptorEventArgs e)
    {
        MessageBox.Show(((InTheHand.WindowsMobile.PocketOutlook.SmsMessage)e.Message).Body, “Message”);
    }

    Download the skeleton project: InterceptorTest.zip (11.08 KB)

  • SelectPictureDialog.LockDirectory property

    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.

  • Fixing the Windows Mobile 5.0 GPS Sample Code

    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


    public double Latitude
    {
        get { return dblLatitude; }
    }


    public double Longitude
    {
        get { return dblLongitude; }
    }


     


    Full details on configuring your device to use GPS are here in Jason’s blog post.

  • Windows Mobile 5.0 Bluetooth Virtual Serial Ports

    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_MACHINESOFTWAREMicrosoftBluetoothSerialPorts


    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_MACHINESOFTWAREMicrosoftBluetoothDevice


    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.


     

  • Disable the Touch Screen

    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.