>>>>>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.
>
>Knowing how it works would be great.. but I think I stated my original problem. The VFPCOM CursorToRS() ... Change a Numeric Value... Call CursorToRS() and the Numeric Value is Blank. If this were Fixed I would be happy for a year. I have done abunch of Digging and The NumericScale,Precision,ActualSize & DefinedSize Properties of a Numeric Value in a Record Set are not so Right.
>
>Erik If you are ever in Northern California I'll Gladly buy you a Beer.
There is code that does the same thing at
www.classx.com. The file is named dbftors.zip or something like that.