Hi Erik, et al...

I still do not know where the confusion lies. Where all of this talk about "crossing COM boundaries" comes from. VFPCOM has several basic functions:

1. Convert ADO Recordsets to VFP Cursors
2. Convert VFP Cursors to ADO Recordsets
3. Create a VFP Event Handler Class via ExportEvents
4. Event Binding

Of the 4 functions, 3 and 4 are the most valuable. If you want to know the basics of how 1 and 2 work, look at Ken Levy's code from a few years ago. That same code, in C++ format of course, is in VFPCOM.

If I have a COM Component that within its boundaries opens a VFP Cursor, If I create an instance of VFPCOM INSIDE the boundaries of that same COM Component, I can then see the VFP cursor, and in turn, I can then create an ADO Recordset. That ADO Recordset can then be passed around.

If VFPCOM is instanced somewhere outside that COM Component boundary, VFPCOM CANNOT see the VFP Cursor.

Now, there are all sorts of problems with the RSToCursor and CursorToRS methods. Personally, I don't find much use for them. If I need to create an ADO Recordset of VFP data, I am going to directly create it. I am not going to go through the bother of an additional step. Besides, when you are dealing with SQL Server or when you wish to make updates, all sorts of problems with VFPCOM exist. I once got a VFP cursor full of nothing but General Fields.

Now, lets go onto David's theory, the one you are so quick to dismiss..< s > The beginnings of VFPCOM probably go back to TechEd 98 in New Orleans. At that time, I had already prototyped something in VB and VFP that did much of the same event binding stuff in VFPCOM. I have been one of the folks leading the charge that if VFP is going to be a player in the middle-tier space, it needs to do 2 things:

1. Respond to Events
2. Create and Raise Events

We got number 1. And, with COM+, we will have number 2 as well. In New Orleans, I met with Randy Brown and we hammered out what eventually became VFPCOM. I was the primary tester for VFPCOM. And, as Dave already guessed, I wrote the primary example that ships with VFPCOM..< bg >.. Notice that I did not address RSToCursor or CursorToRS in my example. I think those methods are marginally useful. You are far better to create ADO Recordsets directly....

Once again, if I need to create an ADO Recordset, I will do it directly like this:

oconn = createobject("adodb.connection")
oconn.open("tastrade")
ors = oconn.execute("select * From customers")

Now, if I needed for some reason to manifest the records as a VFP cursor, I would then do this :

oComUtil = create("vfpcom.comutil")
ocomutil.rstocursor(ors,"cust")

Then again, I might be more tempted to use SQL PassThrough.

You will find by the way, that if you then attempt to re-convert the VFP cursor to an ADO Recordset, it then works.

You have to understand the difference between fabricated RS's and RS's that have knowledge about the underlying schema. My guess is that something gets whacked when you start with a fabricated RS. Most likely, it has to do with data types. Having the schema info available seems to eliminate the problem...

If there is one killer app in taking VFP data and marshaling it to an ADO Recordset, it is in the area of Automation - passing data to Excel, Word, or another COM Server.

The real gem in VFPCOM is all the event binding that can be done. Specifically, because we can now respond to events, we can make use of async processing.

To Recap:

1. The primary focus of VFPCOM is event support

2. The ADO Recordset stuff is riddled with problems and is marginally useful

3. JVP DID have a hand in the design, creation, testing, and documentation of
VFPCOM (I only say this Erik because you are so quick to make a conclusion
when in fact, you have no basis to make that conclusion...< s >...)

4. VFPCOM was actually created by a third party - not the VFP Team directly -
ala the modeling wizards which were created by Max Egger. It's no big
deal. It was a matter of time and getting the proper resources behind the
project so that it could get done....

So to Dave Stevenson, 3 gold stars to you for being so perceptive...< bg >

To Erik Moore, make sure you have all the facts before you go out on a limb with a conclusion. You may find the limb is pretty thin...< bg >

I hope this clears up any conclusion with respect to VFPCOM....




>>>>Guess the ultimate answer is that we will never know how the VFPCOM crosses the COM boundries.
>>>
>>>Hogwash. :-) We just have to ask the right person. I'll corner somebody at the next DevCon.
>>
>>Perhaps JVP will not or cannot say how it's done, because he's under NDA about the details. It's pretty obvious that he had a hand in either writing or documenting VFPCOM, or maybe both.
>
>Documenting, maybe, but I doubt it, and writing it, no. It was written by the VFP team. Anyway, I don't think this sort of thing is what is usually protected by an NDA.
>
>I have a vague idea-
>
>a COM object lives in a dll. All it is is a set of functions, and properties that are accessible by programs that know how to talk to a library through the COM interface- that is using the IDispatch interface to find the addresses of the named functions.
>
>But a dll can also host other functions that don't have to adhere to the COM spec, and VFP does provide hooks into its environment to allow external libraries to call VFP API functions. This is exactly what an fll does. All an fll is, is a dll that knows the names of available VFP API functions, and how to call them. I strongly suspect that VFPCOM.dll hosts both the VFPCOM.COMUtil object, and a set of functions that work like an fll does, calling VFP API functions.