CDO Fields does not work for UserProperties on Windows XP Tablet PC Edition

[Chris Fannin]

I have attempted to discuss this topic at outlookcode.com and vbcity.com,
but received no replies.

Over the past 9.5 months, I have been developing and administering a very
large Exchange + Outlook operations solution. I have been able to get past
every roadblock I encounter -- except this one!

All of the Outlook forms have heavy coding. To make them faster, I
implemented CDO. The CDO works just fine within the Outlook forms for
everyone - including the four XP Tablet PC users. However, I developed a VB6
ActiveX DLL to encapsulate some of the CDO code and provide more intuitive
dialogs throughout the system. The DLL works like a charm for all of us
regular PC users and standard XP laptop users. But... it does not work for
the Tablet PC users. There are two different brands being used, so it's
definitely XP Tablet PC Edition that's the cause.

Specifically, UserProperties cannot be retrieved for them. It gives
MAPI_E_NOT_FOUND anytime the DLL tries to get the value. It does not matter
what form type (Contact or Post) or what UserProperty. On the Tablet PCs,
only standard intrinsic fields will retrieve correctly:

strValue = objMessage.Subject 'WORKS
strValue = objMessage.Fields(&H3001001F).Value 'WORKS
strValue = objMessage.Fields("Account Name").Value 'MAPI_E_NOT_FOUND

Remember.. all of it works perfectly fine on all of the standard computers.
Also, the CDO does work for the Tablet PCs, but only within Outlook Form
script. It also partially works in VB format - it just won't retrieve the
UserProperties.

I'm starting to wonder if there's some type of twisted security permissions
regarding UserProperties via CDO on XP Tablet PC Edition because it works
fine in the form - just not externally in a DLL!!!! And regular XP Pro works
regardless of where it's located.

PLEASE.. if someone can shed some light on this matter, I'd greatly
appreciate it. It's driving me and the Tablet PC users crazy. They are
unable to work efficiently because they have to go to another computer
whenever they need to do something that utilizes the DLL.

If you would like to see my original post, it's here:
http://www.vbcity.com/forums/topic.asp?tid=98318

 

[Michael Bauer]

Hi Chris,

unfortunately I don´t know the answer but am interested in. Please post
if you get it.

 

[Chris Fannin]

It was a stupid solution, but that's what I expected. Since Tablet PC is
nuts, it can't find UserProperties. However, it can if you try to add them
first. So, to get around this problem, instead of referencing the field by
name, I just did an Add instead. This will return the property if it already
exists. More information on the solution can be found in my vbcity.com post:

http://www.vbcity.com/forums/topic.asp?tid=98318

 

[Michael Bauer]

Thanks, Chris. But this works for other PC´s, too: Accessing a
non-existing property returns an error.

 

[Chris Fannin]

As I've stated in all my initial posts - the properties *do* exist and *do*
have values. It worked fine on regular XP computers. It was only the Tablet
PCs that didn't work. Also, they worked when the code was within an Outlook
form.

The issue is not property existence.. it's XP Tablet PC's inability to read
properties using the Message.Fields("Name").Value syntax.

 

[Michael Bauer]

Sorry, Chris. Obviously I haven´t read all your posts attentively
enough.

--
Viele Grüße
Michael Bauer - MVP Outlook

As I've stated in all my initial posts - the properties *do* exist and *do*
have values. It worked fine on regular XP computers. It was only the Tablet
PCs that didn't work. Also, they worked when the code was within an Outlook
form.

The issue is not property existence.. it's XP Tablet PC's inability to read
properties using the Message.Fields("Name").Value syntax.