I’ve written quite a bit about Visual FoxPro interoperating with .NET in the past both for ASP.NET interacting with Visual FoxPro COM objects as well as Visual FoxPro calling into .NET code via COM Interop. COM Interop with Visual FoxPro has a number of problems but one of them at least got a lot easier with the introduction of dynamic type support in .NET. One of the biggest problems with COM interop has been that it’s been really difficult
to pass dynamic objects from FoxPro
to .NET and get them properly typed. The only way that any strong typing can occur in .NET for FoxPro components is via COM type library exports of Visual FoxPro components. Due
to limitations in Visual FoxPro’s type library support as well as the dynamic nature of the Visual FoxPro language where few things are or can be described in the form of a COM type library, a lot of useful interaction between FoxPro and .NET required the use of messy Reflection code in .NET. Reflection is .NET’s base interface
to runtime type discovery and dynamic execution of code without requiring strong typing. In FoxPro terms it’s similar
to EVALUATE() functionality albeit with a much more complex API and corresponiding syntax. The Reflection APIs are fairly powerful, but they are rather awkward
to use and require a lot of code. Even with the creation of wrapper utility classes for common EVAL() style Reflection functionality dynamically
access COM objects passed
to .NET often is pretty tedious and ugly. Let’s look at a simple example. In the following code I use some FoxPro code
to dynamically
create an object in code and then pass this object
to .NET.
An alternative
to this might also be
to create a new object on the fly by using SCATTER NAME on a database record.
How the object is created is inconsequential, other than the fact that it’s not defined as a COM object – it’s a pure FoxPro object that is passed
to .NET. Here’s the code: ***
Create .NET COM InstanceloNet = CREATEOBJECT('DotNetCom.DotNetComPublisher')
***
Create a Customer Object Instance (factory method)
loCustomer = GetCustomer()
loCustomer.Name = "Rick Strahl"
loCustomer.Company = "West Wind Technologies"
loCustomer.creditLimit = 9999999999.99
loCustomer.Address.StreetAddress = "32 Kaiea Place"
loCustomer.Address.Phone = "808 579-8342"
loCustomer.Address.Email = "
[email protected]"
*** Pass Fox Object and echo back values
? loNet.PassRecordObject(loObject)
RETURN
FUNCTION GetCustomer
LOCAL loCustomer, loAddress
loCustomer = CREATEOBJECT("EMPTY")
ADDPROPERTY(loCustomer,"Name","")
ADDPROPERTY(loCustomer,"Company","")
ADDPROPERTY(loCUstomer,"CreditLimit",0.00)
ADDPROPERTY(loCustomer,"Entered",DATETIME())
loAddress = CREATEOBJECT("Empty")
ADDPROPERTY(loAddress,"StreetAddress","")
ADDPROPERTY(loAddress,"Phone","")
ADDPROPERTY(loAddress,"Email","")
ADDPROPERTY(loCustomer,"Address",loAddress)
RETURN loCustomer
ENDFUNC
Now prior
to .NET 4.0 you’d have
to access this object passed
to .NET via Reflection and the method code
to do this would looks something like this in the .NET component:
public string PassRecordObject(object FoxObject)
{
// *** using raw Reflection
string Company = (string) FoxObject.GetType().InvokeMember(
"Company",
BindingFlags.GetProperty,null,
FoxObject,null);
// using the easier ComUtils wrappers
string Name = (string) ComUtils.GetProperty(FoxObject,"Name");
// Getting Address object – then getting child properties object Address = ComUtils.GetProperty(FoxObject,"Address"); string Street = (string) ComUtils.GetProperty(FoxObject,"StreetAddress");
// using ComUtils 'Ex' functions you can use . Syntax string StreetAddress = (string) ComUtils.GetPropertyEx(FoxObject,"AddressStreetAddress");
return Name + Environment.NewLine +
Company + Environment.NewLine +
StreetAddress + Environment.NewLine + " FOX";
}
Note that the FoxObject is passed in as type object which has no specific type. Since the object doesn’t exist in .NET as a type signature the object is passed without any specific type information as plain non-descript object.
To retrieve a property the Reflection APIs like Type.InvokeMember or Type.GetProperty().GetValue() etc. need
to be used. I made this code a little simpler by using the Reflection Wrappers I mentioned earlier but even with those ComUtils calls the code is pretty ugly requiring passing the objects for each call and casting each element.
Using .NET 4.0 Dynamic Typing makes this Code a lot cleaner
Enter .NET 4.0 and the dynamic type. Replacing the input parameter
to the .NET method from type object
to dynamic makes the code
to access the FoxPro component inside of .NET much more natural:
public string PassRecordObjectDynamic(dynamic FoxObject)
{
// *** using raw Reflection
string Company = FoxObject.Company;
// *** using the easier ComUtils class
string Name = FoxObject.Name;
// *** using ComUtils 'ex' functions
to use . Syntax
string Address = FoxObject.Address.StreetAddress;
return Name + Environment.NewLine +
Company + Environment.NewLine +
Address + Environment.NewLine + " FOX";
}
As you can see the parameter is of type dynamic which as the name implies performs Reflection lookups and evaluation on the fly so all the Reflection code in the last example goes away. The code can use regular object ‘.’ syntax
to reference each of the members of the object. You can
access properties and call methods this way using natural object language. Also note that all the type casts that were required in the Reflection code go away – dynamic types like var can infer the type
to cast
to based on the target assignment. As long as the type can be inferred by the compiler at compile time (ie. the left side of the expression is strongly typed) no explicit casts are required.
Note that although you get
to use plain object syntax in the code above you don’t get Intellisense in Visual Studio because the type is dynamic and thus has no hard type definition in .NET .
The above example calls a .NET Component from VFP, but it also works the other way around. Another frequent scenario is
an .NET code calling into a FoxPro COM object that returns a dynamic result.
Assume you have a FoxPro COM object returns a FoxPro Cursor Record as
an object:
DEFINE CLASS FoxData AS SESSION OlePublic
cAppStartPath = ""
FUNCTION INIT
THIS.cAppStartPath = ADDBS( JustPath(Application.ServerName) )
SET PATH
TO ( THIS.cAppStartpath )
ENDFUNC
FUNCTION GetRecord(lnPk)
LOCAL loCustomer
SELECT * FROM tt_Cust WHERE pk = lnPk ;
INTO CURSOR TCustomer
IF _TALLY < 1
RETURN NULL
ENDIF
SCATTER NAME loCustomer MEMO
RETURN loCustomer
ENDFUNC
ENDDEFINE
If you call this from a .NET application you can now retrieve this data via COM Interop and cast the result as dynamic
to simplify the data
access of the dynamic FoxPro type that was created on the fly:
int pk = 0;
int.TryParse(Request.QueryString["id"],out pk);
//
Create Fox COM Object with Com Callable Wrapper
FoxData foxData = new FoxData();
dynamic foxRecord = foxData.GetRecord(pk);
string company = foxRecord.Company;
DateTime entered = foxRecord.Entered;
This code looks simple and natural as it should be – heck you could write code like this in days long gone by in scripting languages like ASP classic for example. Compared
to the Reflection code that previously was necessary
to run similar code this is much easier
to write, understand and maintain.
For COM interop and Visual FoxPro operation dynamic type support in .NET 4.0 is a huge improvement and certainly makes it much easier
to deal with FoxPro code that calls into .NET. Regardless of whether you’re using COM for calling Visual FoxPro objects from .NET (ASP.NET calling a COM component and getting a dynamic result returned) or whether FoxPro code is calling into a .NET COM component from a FoxPro desktop application. At one point or another FoxPro likely ends up passing complex dynamic data
to .NET and for this the dynamic typing makes coding much cleaner and more readable without having
to create custom Reflection wrappers. As a bonus the dynamic runtime that underlies the dynamic type is fairly efficient in terms of making Reflection calls especially if members are repeatedly accessed. © Rick Strahl, West Wind Technologies, 2005-2010Posted in COM FoxPro .NET CSharp
