In case you missed it, Calvin posted an entry a couple of days ago in his Blog that describes how you can hack a typelibrary in order to provide Visual FoxPro COM exports with the ability return properly typed return values of types from the current project as well as overriding property types.
In case you’re not familiar with the issue: VFP is not able to create a COM return type in a type library that can return a complex COM type that exists in the current project. So the following don’t work:
DEFINE CLASS Customer as Session OLEPUBLIC
*** Custom Property with an internal type
MyProperty = null
* Set COM attributes for MyProperty.
DIMENSION MyProperty_COMATTRIB[4]
myProperty_COMATTRIB[2] = "Help text displayed in object browser|Iaddress"
FUNCTION Init
this.MyProperty = CREATEOBJECT("tlbTest.Address")
ENDFUNC
*** Factory method returning a custom type
FUNCTION Create() as Variant HELPSTRING "Get Customer|Icustomer"
RETURN CREATEOBJECT( "TlbTest.Customer" )
FUNCTION GetAddress(PK as integer) as Variant HELPSTRING "Get Address objhect|Iaddress"
RETURN CreateObject( "tlbTest.Address" )
ENDDEFINE
DEFINE CLASS Address as Session OLEPUBLIC
Street = "32 Kaiea"
City="Paia"
State="HI"
ENDDEFINE
If you compile this code and look at the type library neither MyProperty, Create or GetAddress are going to return the proper COM types, but instead return generic Variants.
I had asked Calvin about this functionality – well actually for several VFP versions – and he slung this code at me a few days later (in a less generic form). Leave it to Calvin <g>… There's a bunch of very interesting stuff in that code which demonstrates the use of the TLI object (for typelib parsing) and how to update resources in an existing binary file...
What Calvin’s code does is basically create a new MIDL type interface file by parsing the existing type library. It looks at a special key in the HelpString (|Iinterfacename) and rewrites any entries that have this. It then takes the MIDL file, compiles a new typelibary and adds the typelibrary back into the DLL.
This is a very welcome solution to a nasty problem. Of course it would be a lot nicer if this was built into VFP directly <g>… bitch, bitch, bitch, but then I’ve been asking for this since VFP 6, so I’m not holding my breath.
If you’re interested in this topic of passing objects back and forth over COM with .NET, which prompted this interation in the first place, there is an article I wrote for Advisor (subscriber content only or paper mag) that talks about the issue in more detail along with some workarounds that you can use involving wrapper types with your target COM environment (in this case .NET). Eventually I’ll put these out on the site here when I get some time to clean them up for HTML.
Unfortunately the article went out before I got this code from Calvin or a reference to it, so this will make a good additional piece of information that should work reasonably well if you have a stable object hierarchy that doesn’t change frequently.
Other Posts you might also like