Handling Outlook COM exceptions in .Net

[blueturtle]

Hi,

I has anybody encountered the following behaviour:
COM exception thrown from Outlook, when handled in .Net,
has different HRESULT every time, for the same error..

E.g.
I cause an exception by using a wrong filter in restrict (adding ZZZ)


Outlook.Items inboxItemsCollection;
inboxItemsCollection.Restrict("[ReceivedTimeZZZ >= '#2/23/2006
14:18#'")

I get exception:
"The property "ReceivedTimeZZZ" is unknown."

The value in class System.Runtime.InteropServices.COMException
of ErrorCode is -1317928951

and in another call it will be
ErrorCode -1005453303

on every call (exception), ErrorCode will get a different value.


Is this a known problem ? in Outlook ? Interop ?
It occurs on various methods, not just Restrict.

It is also discussed here:
http://groups.google.com/group/micr...orcode+hresult+outlook&hl=en#bca91332ac0e89f3


Thanks for any help.
Si.

 

[Sue Mosher [MVP-Outlook]]

You may be running up against any or all of these three issues with Restrict:

1) You can use Find and Restrict with custom fields only if those fields have been defined in the folder, not just in individual items. A good test is whether a folder view can show the data in those fields from the User-defined Fields in Folder list of fields.

2) The proper syntax for the field name is to enclose it in square brackets; you have only an open bracket, not a closing bracket.

3) The date element must be enclosed in text quotes, not date quotes and definitely not both kinds of quotes, which is how you have it.

--
Sue Mosher, Outlook MVP
Author of Configuring Microsoft Outlook 2003

and Microsoft Outlook Programming - Jumpstart for
Administrators, Power Users, and Developers

 

[blueturtle]

Hi,
Thanks for your reply.

Using "Restrict" was just a sample how to cause an exception.
It can be seen also on "Outlook.Recipient.FreeBusy" and
"Attachments.Add".
The issue is that in COM, the practice is to compare the HRESULT value
against a list of known numeric values (or test certain bits)
but here, the numeric value seem to be random, and only the description
is the same (at least it's prolog).

As for your comments, this syntax of the filter seems to work fine so
far.
The date element was enclosed with "#", to avoid any ambiguity as
whether 7/4 is July's 4th, or April's 7th.
I didn't find any documentation about the compatibility of the syntax
among OS with different cultures used, so I used this one, which seems
to work.

Itzik.

 

[Josh Einstein]

I've run into this too and in some exceptions I don't even get a
description.

--
Josh Einstein
Einstein Technologies
Microsoft Tablet PC MVP
Tablet Enhancements for Outlook 2.0 - Try it free for 14 days
www.tabletoutlook.com