Pocket Outlook Woe 01: incoming server and outgoing server are passed as two NULL pointers from Outlook to Transport
====>SiteMap of this Blog<===
Pocket Outlook Woe 01: incoming server and outgoing server are passed as two NULL pointers from Outlook to Transport
I've briefly mentioned how to write a transport plugin for Pocket Outlook in two of my previous posts:
- TransportDemo sample in Pocket PC 5.0 SDK does not work? Check the solution here...
- How to programmatically query mail account information in Windows Mobile devices, for example, incoming server and username?
In Pocket Outlook, each mail account is associated with a MAPI store, and a transport. A store is a store, for storing email folders and email messages. The transport is responsible for synchronizing a mail account by talking to the remote server. The main reference on CEMAPI can be found in MSDN's Windows Mobile SDK Messaging section, and the main interface a transport must implement is called IMailSyncHandler.
In Windows Mobile 5.0 devices (and some newer version of Pocket PC 2003 SE devices), a newer version of Pocket Outlook is shipped. This updated version seems bringing a couple of woes to transport developers. Today I am focusing on the first one: Incoming server and outgoing server are passed by Outlook as two NULL pointers to the transport.
The method involved is Install, which is called by Outlook to install the transport and then passes the configuration information to the transport.
HRESULT Install ( LPCWSTR pszProfileName, LPCWSTR pszIncomingServer, LPCWSTR pszOutgoingServer, GUID * pidNetwork );
- pszProfileName
- [in] Profile name of the transport instance, which is also the account name.
- pszIncomingServer
- [in] Incoming server name that the transport should use to synchronize the e-mail into the device.
- pszOutgoingServer
- [in] Outgoing server name that the transport should use to send outgoing e-mails.
Incoming server and outgoing server can be either specified by the user who create the account via Outlook's New Account Setup wizard, or created by the developer using DMProcessConfigXML and EMAIL2 CSP.
I tested both cases, and found that two NULL pointers are always passed from Outlook to the transport. The testing transport is the TransportDemo sample in Windows Mobile SDK. In its Install method, a dialog is used to display two server strings passed by Outlook
Case 1: TransportDemo1 is created by the user using Outlook's wizard
In New Account Setup Wizard, typing the incoming mail server name and outgoing mail server name.
When the transport (TransportDemo) is loaded, two NULL pointers are passed from Outlook.
Case 2: TransportDemo2 is programmatically created using DMProcessConfigXML
The account information can be queried back successfully, showing the two server names correctly. Refer here for how to programmatically query mail account information in Windows Mobile devices, for example, incoming server and username.
Unfortunately, you'll still get two NULL pointers.
Wrap Up
I tried to disable the device security, or sign the transport DLL using a certificate, but the problem persists.
This seems affecting not only Windows Mobile 5.0 device, but also newer version of Pocket PC 2003 SE device, where the newer version of Outlook is shipped.
As a workaround, the transport developer might use registry to store the sever information, rather than relying on Outlook. However, this means that the user cannot change the server settings via Outlook.
The POP3 transport and IMAP4 transport shipped along with Pocket Outlook seem immune to the issue. Could it because the TransportDemo code is too simple and not implement necessary methods??