ListChanged in PocketOutlook on Windows Mobile 5.0

I've been working on a calendar application for the Pocket PC. Now that Windows Mobile 5.0 devices are shipping, I figured I should ensure my application works on Windows Mobile 5.0. There is one feature I added that doesn't work anymore--my application doesn't receive notification when the calendar changes. For previous versions of the Pocket PC, I was able to trap changes to the appropriate CEDB property database via some C++ code. However, Windows Mobile 5.0 uses a new, and incompatible, database to store PIM information, so my change hook from before doesn't work.

I was thus very excited to discover Microsoft had shipped a managed assembly for use on Windows Mobile 5.0 that supports receiving change notification. Their assembly, Microsoft.WindowsMobile.PocketOutlook has a number of classes that correspond with POOM (Pocket Outlook Object Model) objects. In particular, the PimItemCollection class contains an event called ListChanged. Perfect! Or so I thought.

Testing this code when changing or adding an appointment using the Calendar application didn't work. What gives? It turns out the ListChanged event doesn't receive change notifications from the operating system. Instead, it only tells you of changes made "to the collection." In other words, if your application uses the managed classes to modify, add, or remove an appointment, your application will be notified. If any other application changes the calendar (or any of the other supported databases), you do not receive notification. In other words, you can use the managed event to keep your application current with the data in the database. This is documented in the Wiki article Windows Mobile 5.0 Managed Documentation for the Windows Mobile APIs on Channel 9.

So, I'm back to adding C++ code that will support Windows Mobile 5.0.

Related Articles

What's New for Developers in Windows Mobile 5.0

A Sandbox for Beta Software

I've been working on a new Pocket PC application, and I'm almost done. I built and tested the application on Pocket PC 2003, but since Windows Mobile 5.0 (WM5) devices are now coming out, I figured I should test my application on WM5. This turned out to be a lot more difficult than I anticipated--not to make it work, but to get my development environment setup so I could even test on WM5 without buying a new device.

My first step was to download and install the Windows Mobile 5.0 SDK. However, as soon as I ran the installer, it told me I couldn’t install the WM5 SDK without first installing Visual Studio 2005. However, VS 2005 hasn't been released yet and the last time I installed Visual Studio 2005 Beta 2 on my computer, I had all sorts of problems debugging an Outlook add-in with Visual Studio 2003. At the time, Microsoft tech support said I had no choice but to remove Visual Studio 2005 and then rebuild my machine. Yikes!

That's when I decided to build a virtual machine to run VS 2005. I setup a new machine in Virtual PC, installed Windows XP Professional, installed Visual Studio 2005 Beta 2, and finally installed the Windows Mobile 5.0 SDK. Everything worked just fine, except for one minor problem--speed. Even on my 3 GHz hyper-threading Pentium IV with 2GB of RAM, it was pig slow. Well, actually, it wasn't even that fast. When it took 5 minutes between pressing F5 and having my program finish starting up in the WM 5 emulator, I decided this just wasn’t going to work.

Then I ran into someone who suggested I try VMWare instead. He mentioned that VMWare, for some reason, runs a lot faster than Virtual PC. I downloaded a 30-day trial version of VMWare workstation, went through the whole install drill again (another day spent installing), and was ready for a try. To my amazement, I've learned that running Visual Studio 2005 and the Windows Mobile 5.0 emulator in VMWare is significantly faster. It's now almost as fast as Visual Studio 2003 and the Pocket PC 2003 emulators running natively on my machine. Amazing!

There are a few other features in VMWare that have made me decide to buy a copy, even though I already purchased a copy of Virtual PC:

• VMWare, unlike Viritual PC, has full support for USB devices. This means you can connect your Pocket PC or Smartphone to ActiveSync running inside a virtual machine. Sweet!
• VMWare has superior support for ISO image files. The version of Visual Studio 2005 I installed in the virtual machine was a release candidate I downloaded. I simply told VMWare to mount this file as the CD, and up popped the setup program. Virtual PC didn't allow mounting this same image file because it was too large.
• Hyper-thread Support: I haven't confirmed this, but it seems like VMWare actually takes advantage of the "extra CPU" in my hyper-threaded host, whereas Virtual PC definitely doesn't.

A final note about VMWare. I encountered a problem installing the Longhorn beta (as well as Windows XP SP2) into a VMWare session. The problem has to do with PAE support of the operating systems. Here is a link to more information about this issue.

VMWare article about PAE Error