Month: January 2009

Posted on

VARIANTs on Fox

As I mentioned previously, I have been experimenting with integrating our application with Maximizer CRM.  Working with their SDK, it doesn’t take long to figure out that the com interfaces were designed with VB and C++ programmers in mind.  Most of it works with VFP, but there are a few exceptions.  I ran into a problem with an interface that accepts a variant variable by reference.  I was surprised to find out that Fox can’t create a variant.

Shirley I can’t be serious?  Everyone knows that all variables in Fox are variants.  While that may be true, Fox can’t create a variable of type variant that can be passed to com components.  Fox always assigns a type to a variable.  Even a simple local myvariable statement creates a logical variable.  Attempting to pass the variable by reference to a com component may result in a “type mismatch” error.

This isn’t entirely Fox’s fault.  After all, should a COM component assume that the calling environment can create a variant?  Microsoft concedes this is a problem in C++ with MFC components and recommends using ATL instead (see link below).

So, what can you do if you run into this situation?  Ideally, the COM interface would be changed not to use variants, but I doubt Maximizer will change their interfaces, in place for years, just so I can use VFP.  VB does allow you to create variables of type variant, so I created a VB wrapper component.  VFP passes a string to the VB component, the VB component converts that to a variant and passes it to the Maximizer component.  It’s not an ideal solution, but it works.

Prb: ActiveX controls passing variant* back to VFP cause error

Posted on

VFPS: Visual FoxPro Stack

UPDATE: This article is now online for free at http://www.foxrockx.com/seite.htm.
——————-
The January 2009 issue of FoxRockX begins with an article by Ken Levy called “Visual FoxPro Stack”:

“VFPS is a Visual FoxPro Stack, an acronym used to define the key software components making up the Visual FoxPro platform and ecosystem. As a starting point, below is a list of components that comprise VFPS:  Visual FoxPro 9.0, Sedna and XSource, VFPX, VFPY. Also included are VFP 3rd Party products including tools related to .NET for Visual FoxPro such as VFP Studio, Guineu, .NET Extender for VFP, VFPCompiler for .NET, and VFPConversion.”

These components represent the future of FoxPro development.  I guess I’ve considered VFPX to be the main effort in that regard, but these other third-party products should not be ignored, as many may find themselves working with them.  Besides, VFPX is primarily an effort for developers, wherease VFPS is aimed at business decision makers.  Ken compares it to LAMP (Linux, Apache, MySQL, PHP) as a marketing moniker and adds the following:

“Having an umbrella stack for evolving VFP community components adds awareness and enhanced branding…  While there will not be a VFP 10.0, there is great benefit from enhancing the mindset and perception by referring to VFPS as the latest bundle of VFP related components. This branding will often target businesses and decision makers of VFP based application development.”

Hopefully, they will put the entire article online for all to see.  I recommend subscribing to FoxRockX.  It will be interesting to see how this all develops.

VFPS Home Page (Fox Wiki)

Posted on

DAO does VFP data natively

I ran across something interesting (albeit of limited use) recently.  We are considering integrating Maximizer CRM with our software, and I’ve been doing some proof-of-concept work along those lines.  One thing about CRM software creators is they know they won’t be replacing your core line of business applications, so they make sure there are plenty of ways to integrate with those apps.  Maximizer is no exception, and being around for quite a few years now, it includes some old-school (but new to me) integration techniques.

The first thing I wanted to do was import some Fox data into Maximizer.  While older products often included native support for dbase and FoxPro 2.x tables, virtually no products supported Visual FoxPro natively, so I was surprised to see FoxPro 3.0 in the list.  I use VFP 9.0, but I haven’t made use of any of the new database features added in versions 7.0 – 9.0.  So, I gave it a try and it worked like a charm.  “Wow, that was easy”, I thought, “I wish Microsoft products supported their own database this well.”

Well, it turns out, they used to.  To my surprise, this all led me to the fact that DAO 3.5 had native support for Visual FoxPro tables.  DAO (data access objects) was Microsoft’s data technology that preceded ado (ActiveX data objects) and was popular with access and VB developers at the time.  It is now deprecated, but some access developers still favor it over newer technologies.  It has been my assumption that Microsoft access got its name because it could “access” multiple databases in addition to its own jet database.  It has done this by means of “ISAM filters” for other databases, including FoxPro.  DAO 3.5 included a filter for Visual FoxPro.

Eventually, ado came along and superseded DAO as the recommended way to access data.  The ISAM filters became part of the Microsoft jet 4.0 engine, but the FoxPro filters were no longer included in the package.  WTF?  Yet another slight against our beloved Fox?  Perhaps, but also consider this: the ISAM filters suck.  While I am sure they work fine for FoxPro 2.x data, the VFP filters are limited and give you read-only access to data.  Compared to the FoxPro ODBC drivers, which give full read/write access as well as much improved performance, it became apparent that ODBC was the preferred way to access FoxPro data and I assume that’s why the ISAM filters were removed.

While I would never recommend DAO for new development, we often find ourselves working with older systems and technology.  It’s interesting what you run across.

Resources: