>>I have found that a simple COM object takes about a sixth of the time it takes to instantiate a native VFP Custom class.
>
>Wow - are you sure about that??? VFP can't use Dual Interfaces when binding to COM
>objects so it has to use IDispatch with GETIDOFNAMES and Invoke() which are rather
>slow. I have to check that out, but I really find that hard to believe unless your
>VFP custom class has a stack of public interfaces.
>

Here is the code I used to test it.

*-- Create a VFP object based on a custom class
lnMemory = VAL(SYS(1016))
lnSeconds = SECONDS()
DIMENSION a[100]
FOR i = 1 TO 100
a[i] = CREATEOBJECT("cDate")
a[i].SetDate({01/02/97})
ENDFOR
? "That took "+STR(SECONDS()-lnSeconds,6,2)+" using "+STR(VAL(SYS(1016))-lnMemory)+ " bytes"

RELEASE a

*-- Here's the same thing but instantiating a COM object created using ATL
lnMemory = VAL(SYS(1016))
lnSeconds = SECONDS()
DIMENSION a[100]
FOR i = 1 TO 100
a[i] = CREATEOBJECT("Date.Date.1")
a[i].Date = {01/02/97}
ENDFOR
? "That took "+STR(SECONDS()-lnSeconds,6,2)+" using "+STR(VAL(SYS(1016))-lnMemory)+ " bytes"
RELEASE a


DEFINE CLASS cDate AS CUSTOM
date = {}
datestring = ""
PROCEDURE SetDate(tdDate)
this.date = tdDate
this.UpdateString()
ENDPROC
PROCEDURE UpdateString
DateString = DTOC(this.Date)
ENDPROC
ENDDEFINE

After executing the program a few times. The first loop takes a total of 0.62secs and the second takes 0.20 seconds. This is a little slower than previous because I have since modified the COM date class and it is now updating two strings evertime you set the date!

>>Calling methods and accessing properties is straightforward and the marshalling that is done during automation calls makes it easy to pass strings between VFP and C++.
>
>No marshalling is required since COM objects are typically in-process.
>But yeah, COM allows you to create C++ classes that are accessible externally.
>

Thanks for the correction. However, I have a related question. I have read about the allocation of memory from a local memory pool and a shared memory pool. If I understand correctly, the COM object can allocate memory from its own local memory pool, or can use a shared memory pool for passing parameters between the COM object and the client. If the COM object is in-process what is the name of the thing that the memory is local to or shared between?

>The thing I hate about ATL is having to deal with the OLE type conversions
>and which of the 50 or so to use ... the subtle differences can really
>throw you for a loop especially when dealing with binary string data...

Binary string data ha! It took me hours to find OLE2T() to convert a standard string. It has been a while since I've done any C++ and this was a rude awakening.

I noticed you posting on msnews.public.adc, maybe you can enlighten me. Am I guessing correctly that the next version of VFP is likely to be released with the latest version of ADO (RDS) and we will be able to bind user interface controls to field objects?

If you don't mind me asking even more questions, do you know what this Advanced Data Space is and how does it relate to the implementation of business objects?

Let me know it you find any contrary results as far as performance with the COM object.

Darrel