Update:
This issue was fixed in Redemption 5.2:
Previously, named MAPI properties in the "string" namespace specified in the DASL format ... always assumed to be of string type (PT_UNICODE or PT_STRING8).
It is now possible to explicitly specify the property type, e.g. PT_LONG (=3):
http://schemas.microsoft.com/mapi/string/{00020329-0000-0000-C000-000000000046}/MyIntegerUserProperty/0x00000003
I am using Redemption 5.1 (and Outlook 2010/64) and have run into this very annoying case:
When trying to write an object of byte[]
to a property it writes it as an PT_MV_LONG
property, not as PT_BINARY
.
This occurs when either using RDOProp.Fields
:
RDOItem rdoItem = GetRDOItem();
// note this is typed PT_BINARY
string dasl = "http://schemas.microsoft.com/mapi/string/{312FD430-D997-418A-8E1F-8D224FE69F5D}/MyProp/0x00000102";
byte[] data = GetSomeData();
rdoItem.Fields[dasl] = data;
...or when using RDOUtils.HrSetOneProp
:
// this also sets MyProp, but does so as PT_MV_LONG, not PT_BINARY
RDOUtils utils = CreateUtils();
var mapiObject = rdoItem.MAPIOBJECT;
var propTag = utils.GetIDsFromNames(mapiObject,
"{312FD430-D997-418A-8E1F-8D224FE69F5D}",
"MyProp");
utils.HrSetOneProp(mapiObject, propTag, encoded);
The above code does not compile, but the types are correct.
Update:
With the string property the way it is above, Redemption is creating the property "MyProp/0x00000102", and not "MyProp".
The first snippet looks perfectly fine to me. I had no problem with the following script executed from OutlookSpy (click “Script Editor” button on the OutlookSpy toolbar, paste the script, click Run). You might have to deselect the message and select it again to see the newly added property. The second snippet does not set teh property type (PT_BINARY).
dasl = "http://schemas.microsoft.com/mapi/string/{312FD430-D997-418A-8E1F-8D224FE69F5D}/MyProp/0x00000102"
dim data(2)
data(0) = 0
data(1) = 1
data(2) = 2
set Session = CreateObject("Redemption.RDOSession")
Session.MAPIOBJECT = Application.Session.MAPIOBJECT
set msg = Session.GetMessageFromID(Application.ActiveExplorer.Selection(1).EntryID)
Msg.Fields(dasl) = data
Msg.Save
Update:
This issue was fixed in Redemption 5.2:
Previously, named MAPI properties in the "string" namespace specified in the DASL format ... always assumed to be of string type (PT_UNICODE or PT_STRING8).
It is now possible to explicitly specify the property type, e.g. PT_LONG (=3):
http://schemas.microsoft.com/mapi/string/{00020329-0000-0000-C000-000000000046}/MyIntegerUserProperty/0x00000003
Well, don't I feel dumb for asking my question and then answering it... anyway, here is what seems to be happening:
Redemption (5.1.0.0) does not seem to understand a property in the form, at least in context of RDOItem.Fields
:
http://schemas.microsoft.com/mapi/string/{312FD430-D997-418A-8E1F-8D224FE69F5D}/MyProp/0x00000102
It takes everything after the property namespace as the property name, or MyProp/0x00000102
in this case, and the tip-off was that it was creating a property with a funny name. I'm still not sure if it's possible to specify the name (not tag) and type in this manner with Redemption (pointers would be nice...)
The following does work, albeit it is a bit cumbersome:
RDOUtils utils = CreateUtils();
var mapiObject = rdoItem.MAPIOBJECT;
var propTag = utils.GetIDsFromNames(mapiObject,
"{312FD430-D997-418A-8E1F-8D224FE69F5D}",
"MyProp");
propTag = ((propTag >> 16) << 16) | 0x0102; // add proptype
utils.HrSetOneProp(mapiObject, propTag, byteArray);
User contributions licensed under CC BY-SA 3.0