Thanks for the reply Dmitry.

So your thinking was that the Class property is just a redundant incarnation
of runtime type info? That makes sense, and is also convenient to implement
in mixed RDO/OOM code.

btw, the elegance of the way all RDO*Item objects derive from RDOMail is not
lost on me at all. In fact I went to lengths trying to explain exactly that
to the folks that sign the checks... I failed miserably, of course, they had
not a clue as to what I was on about, but if nothing else they now associate
the words "RDO" and "elegant" (so I will take the "win" anyways.) :-)


Thanks again,
MM



"Dmitry Streblechenko" wrote in message
...
Unlike OOM, all item related objects (RDOContactItem, RDOAppoitmentItem,
etc) in RDO are derived from the generic RDOMail object, which represents
regular messages and is anequivalent of the MailItem object in OOM.
So any item object can be accessed using RDOMail. If oyu need item
specific properties (e.g. RDOContactItem.Email1Address), you can use "is"
and "as" operators (VB and .Net) or TypeName in VB.

--
Dmitry Streblechenko (MVP)
http://www.dimastr.com/
OutlookSpy - Outlook, CDO
and MAPI Developer Tool
-
"Mark McGinty" wrote in message
...
Greets,

Unlike OOM objects, RDOMail objects (and derivations) do not expose a
Class property (in OOM, type Outlook.OlObjectClass.) I have been working
around this (converting a substantial project that relies heavily on
.Class) by interpolating RDOMail.MessageClass... but isn't that going to
screw me if custom forms are being used?

In a couple of places I used the containing folder's DefaultItemType,
which may not necessarily be definitive but, otoh, will not be affected
by custom forms. Is there another equivilent?


TIA,
MM