Within C# this is easy, simply pass it as "Object", but from OE the COM-HANDLE doesn't map to object and I can't cast it to "System.Object" pass.
I have also tried changing the signature of the C# method to accept the UserProperty as the Interop type, but once again that fails.
Any suggestions as to how to do this ?
In C# it is easy because your reference to the COM object is already a C# object wrapper. In the ABL the COM-HANDLE is a completely different animal. It is not a wrapper and it's not an "object" in our OO sense.
Was there something more to this post, i.e., something before this last post on Aug 8 at 8:40? It seems to be out of context. Where are you getting this COM-HANDLE from? Shouldn't you be using the C# version of the COM object to begin with i.e., the C# wrapper?
We have code that generates User Properties on an Outlook MailItem in ABL, from existing code.
We also do the same thing in our C# VSTO addin.
However I need to mark the UserProperty as none printable, which I can do using reflection in a C# dll, and is working in the VSTO addin, and I want to share the same code (as I can't see a way to do the same thing in ABL via the com handle).
the C# code for the disabling print:
public void DisablePrint(object customProperty)
{
long printablePropertyFlag = 0x4; // PDO_PRINT_SAVEAS
string printablePropertyCode = "[DispID=107]";
Type customPropertyType = customProperty.GetType();
// Get current flags.
object rawFlags = customPropertyType.InvokeMember(printablePropertyCode, BindingFlags.GetProperty, null, customProperty, null);
long flags = long.Parse(rawFlags.ToString());
// Remove printable flag.
flags &= ~printablePropertyFlag;
object[] newParameters = new object[] { flags };
// Set current flags.
customPropertyType.InvokeMember(printablePropertyCode, BindingFlags.SetProperty, null, customProperty, newParameters);
}
If there's a way to replicate this purely in ABL i'll give it a go, but I can't 'GetType()' on a com-handle either.
I appreciate this is a real edge case.
Peter
In addition i've just tried it from a C# dll that creates a Word.Application object and returns that as a parameter.
Similar problem - you can assign the property to a COM-HANDLE which is the object, but it's an invalid handle.
So the problem occurs in the opposite direction as well (C# to ABL as well as ABL to C#).
Why can't you just try to set the property (printablePropertyCode) using the COM-HANDLE. I don't understand why the C# code is doing this through reflection.
It's because it's not a public property - i.e. it has no property name only a dispid.
So I can update the property using reflection, but not via the properties visible on the COM-HANDLE, and unfortunately it's not an interface I have any control over.