In The Hand Ltd

Category: Windows Mobile

  • Reading E-Mail Through MAPI on Windows Mobile 5

    Here is another issue I’ve been banging my head against a brick wall with and the workaround – although it’s not a pleasant workaround by any measure.


    To read the body text of an email message under WM2003 you open the PR_BODY property of the message and this gets you the plain text body of the message, no headers, no fancy encoding – just the facts! However in Windows Mobile 5 this now returns an empty stream. So how do we get at the body of the message, the Messaging application certainly knows how to. Well the answer from Microsoft is that although this change in behaviour is not documented you must now change your approach. Instead you need to access the PR_CE_MIME_TEXT property (defined in cemapi.h). This contains the entire message, header and all, and may require you to deal with mime encoded body. My first impression of this is that it’s a backwards step which unnecessarily breaks existing code, you’d expect the API to deal with the underlying implementation and decoding and have the properties such as PR_BODY exposed to the outside world. Ah well, progress I guess…

  • Issue with Microsoft.WindowsMobile.PocketOutlook.RecipientCollection.Add()

    When you want to create a meeting request with managed POOM on WM5.0 you start by creating an Appointment and then add Recipient objects to it’s Recipients collection. However what the documentation doesn’t tell you is that you have to ensure that your Recipient has both the Name and Address properties. For example:-


    Microsoft.WindowsMobile.PocketOutlook.Appointment ma = new Microsoft.WindowsMobile.PocketOutlook.Appointment();
    ma.Subject = “Test 5”;
    ma.Recipients.Add(new Microsoft.WindowsMobile.PocketOutlook.Recipient(“user@yourdomain.com“));


    Will throw a Win32Exception with the text “Native method call failed”. This isn’t very descriptive but the reason it fails is due to how native POOM works – the IRecipients.Add method takes a name argument and since your Name property is empty this call fails. If you specify the name e.g.


    ma.Recipients.Add(new Microsoft.WindowsMobile.PocketOutlook.Recipient(“User”,”user@yourdomain.com“));


    or even this if you only have an address:-


    ma.Recipients.Add(new Microsoft.WindowsMobile.PocketOutlook.Recipient(“user@yourdomain.com“,”user@yourdomain.com“));


    Then you’ll be okay.

  • AKU 2 = Woohoo

    Some great news from Jason Langridge – not only will AKU 2 introduce the long awaited messaging feature pack, but also introduce the A2DP (Advanced Audio Distribution Profile) Bluetooth profile to support mono and stereo audio devices such as headphones and some advanced car kits. ETA is early 2006 depending on individual OEM schedules for ROM updates.

  • One-handed Pocket PC Applications

    Mark has posted the final version of his MSDN article on designing for stylus-free usage on Windows Mobile. This covers both what you get for free in .NETCF v2.0 for navigating around forms with the d-pad and also what you can do to make some of the other intrinsic controls behave. Mark’s sample code includes wrappers around these “badly behaved” controls such as the DateTimePicker.

  • Making the SDK Documentation more discoverable

    I like John Kennedy‘s proposed SDK TOC for Windows Mobile. And since the sample contains valid links, I was surpised at the amount of content I found which I’d not been able to locate before 🙂


    While there will always be cases when organising content like this you could end up in heated debates about whether article x belongs in category y or z, I believe it’s a definate improvement and gives better visibility of the scope and content of the SDK documentation. I particularly like the fact that Whats New is the first category with itemised details for each update – the SDK documentation has already received two batches of updates.


    Update: I’ve realised there isn’t any Telephony content on this contents page. It would be good to have an entry for Telephony (which is an important part of most Windows Mobile devices) and it should link through to TAPI, Phone, SMS and SIM topics.

  • All These New Devices

    There has been a lot of activity recently on new Windows Mobile 5.0 devices, in a few cases official announcments, in some cases details leaked through common sources such as the FCC site where products sent for testing are publically detailed.


    One of the interesting models to be revealed has been discussed by WallabyFan, with the original scoop at the register. The unique feature of this device is that it is the first Windows Mobile Smartphone to feature a built in GPS. The feature has previously been available on a small number of Pocket PC devices, most recently in the iPaq 65xx range.


    HTC are busy with Pocket PC devices in the form of the Universal, and the Wizard – successor to the Magician (iMate JAM and equivalents), and also new Smartphone models such as the Tornado – a WiFi equipped Smartphone.


    All in all it looks like a lot of exciting new devices will bring Windows Mobile 5.0 to the market place.

  • Functionality in InTheHand.WindowsMobile.Forms

    As has already been shown with some of the other libraries in WindowsMobile In The Hand, the object model is generally designed to follow the Windows Mobile 5.0 APIs. There are a few examples where new functionality is exposed which is not found in the WM 5.0 APIs, some of which was designed specifically to complement Windows Mobile 5.0.


    In the case of the Forms assembly, none of the WM5.0 forms are supported, this is because functionality such as CameraCaptureDialog and SelectPicture dialog rely on new functionality in the underlying OS – prior to WM 5.0 each OEM implemented their own camera support.


    However in WindowsMobile In The Hand, a few new pieces of forms related functionality are added:-



    The MessageBox is designed to provide a softkey-enabled message box for Windows Mobile 5.0 Pocket PCs (although it can also be used on prior versions). When used in a Smartphone project it uses the standard compact framework implementation, on a Windows Mobile 5.0 Pocket PC it produces the following:-



    It’s been designed to follow the Smartphone experience so you can provide the same user experience on both platforms. It supports a full range of overrides for the Show method to specify buttons, icon etc. Here the MessageBoxIcon is used to draw a watermark image on the dialog, similar in spirit to the themed icons which are used on the Smartphone equivalent.


    MobileDevice provides a few helper methods to reset the device, and get the platform type identifier e.g. PocketPC or Smartphone.


    MobileKeys provides a mapping between the device specific key constants (as defined in winuserm.h) and the desktop key codes, so all of the members are of type System.Windows.Forms.Keys.


    OpenFileDialog is built specifically for Windows Mobile 5.0 Smartphone and matches the System.Windows.Forms version available in Pocket PC projects. Again if used in a Pocket PC project it utilises the existing implementation in System.Windows.Forms. It will currently raise a NotSupportedException if used on a Smartphone 2003 device.

  • Restricting Pim Item Collections

    This applies equally to WindowsMobile In The Hand and the Windows Mobile 5.0 APIs. On the collection classes there exists a Restrict method which returns a subset of the collection matching your search query. You can use the resulting collection to databind or otherwise enumerate over.


    The query language used is similar, but not the same, as SQL: if you imagine that what you are entering here is just the WHERE clause of a query you will not be far off. The key rules to follow are:-



    • Field names must match exactly – refer to the Properties of the Appointment, Contact and Task class for valid field names
    • Field names must be enclosed in square brackets e.g. [MobileTelephoneNumber]
    • You can combine multiple expressions with AND and OR
    • Supported operators are < (Less Than), <= (Less Than or Equal To), > (Greater Than), >= Greater Than or Equal To), = (Equals), <> (Not Equals)
    • Items without the property set will not be returned in a query. So if you set a query of [BusinessAddressCity] = “London” it would not return items without the business address city present even though these are not London.
    • You can use this knowledge to form a query to return all records where the property is set with [PropertyName] <> “” as all items with the property set will match this pattern.

    You can return a full contact list for all items with a mobile number using this code:-


    os = new OutlookSession();

    PimItemCollection pic = os.Contacts.Items.Restrict(“[MobileTelephoneNumber] <> “””);

    listBox1.DataSource = pic;


    listBox1.DisplayMember = “FileAs”


    This example bind the collection to a control, the list will show the contact name only but you’ll be able to retrieve the Contact object from the SelectedItem property of the list box to use it’s other properties (e.g. the mobile number).


    For Windows Mobile 5.0 you can use the new ChooseContactDialog which features a RequiredProperties property so you can easily setup the dialog to show only relevant items.


    Update: Here is the VB equivalent:-


    os = New OutlookSession
    Dim pic As PimItemCollection = os.Contacts.Items.Restrict(“[MobileTelephoneNumber] <> “ & Chr(34) & Chr(34))
    ListBox1.DataSource = pic
    ListBox1.DisplayMember = “FileAs”


     

  • 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

  • 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.