![]() |
RDO Question
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 |
RDO Question
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 |
RDO Question
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 |
All times are GMT +1. The time now is 12:22 PM. |
Powered by vBulletin® Version 3.6.4
Copyright ©2000 - 2025, Jelsoft Enterprises Ltd.
Search Engine Friendly URLs by vBSEO 2.4.0
Copyright ©2004-2006 OutlookBanter.com