RDO Question

[Mark McGinty]

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

 

[Dmitry Streblechenko]

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)

-

"Mark McGinty" <mmcginty@spamfromyou.com> wrote in message

news:%23QVL5l8eKHA.2160@TK2MSFTNGP02.phx.gbl...
> 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

>

 

[Mark McGinty]

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" <dmitry@dimastr.com> wrote in message

news:%23VA3E7BfKHA.6096@TK2MSFTNGP02.phx.gbl...
> 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)
>

>

>

> -
> "Mark McGinty" <mmcginty@spamfromyou.com> wrote in message
> news:%23QVL5l8eKHA.2160@TK2MSFTNGP02.phx.gbl...
> > 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
>

>
>>

>