Hi Mark.

>Most of the code my builder creates is written to the INIT of each CA subclass.

You have to be careful about that. Cursor and CursorAdapter are weird in that if you instantiate them in code, the Init method fires first (as you'd expect) but in the DE of a form, Init fires fairly late. The order of events is:

DataEnvironment.OpenTables
DataEnvironment.BeforeOpenTables
CursorAdapter.AutoOpen
CursorAdapter.BeforeCursorFill
CursorAdapter.CursorFill
CursorAdapter.AfterCursorFill
CursorAdapter.Init
DataEnvironment.Init

So, code in Init will fire too late if it's needed in CursorFill.

The CursorAdapter builder gets around this in an admittedly goofy way: the following code is inserted into AutoOpen:

if not pemstatus(This, '__VFPSetup', 5)
This.AddProperty('__VFPSetup', 1)
This.Init()
endif

This ensures that Init is called before CursorFill. However, since Init may have already been fired if the CA was instantiated in code, you have to avoid executing the code in Init again. That's handled with the following code in Init:

local llReturn
do case
case not pemstatus(This, '__VFPSetup', 5)
This.AddProperty('__VFPSetup', 0)
case This.__VFPSetup = 2
This.__VFPSetup = 0
return
endcase
... other code here
if This.__VFPSetup = 1
This.__VFPSetup = 2
endif

>However, I have the builder directly populating the CursorSchema property since this is necessary in order to have fields available from the CA in the DE for dropping onto the form or to have the fields available from the COntrolSource combo in form objects. This is a very crippling limitation when it comes to form design.

Yeah, that bites. Hopefully we'll see some relief from this limitation in Europa.

Doug