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
