Hi thomas,

Thanks for taking the time to look into this in details and thanks for the kind words.
Indeed, the errors you spotted are bugs that I need to fix, and you're right, a central error handling routine might be a good idea.

Yes, the THIS_ACCESS method and BINDEVENT() function are interesting concepts to implement just-in-time evaluation, implementing ORM (kindoff), and interfacing.

One that falls in the same category is the collection.item method. This should also allow for adding something to a collection at the time its referenced and could make our lives easier.

I'm still thinking of implementing something like

oRm.Data(cField).Value
oRm.Data(cField).Oldvalue
oRm.Data(cField).HasChanged()
oRm.Data(cField).Revert()
oRm.Data(cField).Blank()
oRm.Data(cField).IsNull()
oRm.Data(cField).IsEmpty()
oRm.Data(cField).IsBlank()

oRm.RecordHaschanged()
oRm.SetBuffermode(nMode)

etc...

Walter,

>Hi Walter,
>
>>So the reason for the TRY CATCH arround the TABLEUPDATE() really is due to a VFP bug, nothing else.
>ok,
>
>My take on the manager...
>Either you forgot the return llRet in delete and setting llRet to true in successful try of Addrecord or you have
>no consistent return strategy - in the Test code you don't check it.
>I'll guess that these 2 are just omissions, but for such simple templates my personal way of coding would be more on the turn of
>

>	FUNCTION AddRecord()
>		LOCAL lHasErr, loErr
>		
>		THIS.oErr = NULL
>		TRY
>			APPEND BLANK IN (THIS.Alias)
>		CATCH TO loErr
>			THIS.oErr = m.loErr
>                         llHasErr = .t.
>		ENDTRY
>		RETURN not m.llHasErr
>	ENDFUNC
>*-- or even
>	FUNCTION Delete()
>		LOCAL lHasErr, loErr
>		
>		THIS.oErr = NULL
>		TRY
>			DELETE IN (THIS.Alias)
>		CATCH TO loErr
>                         llHasErr = this.ErrorCalleeMeth(m.loErr, sys(16))
>		ENDTRY
>		RETURN not m.llHasErr
>	ENDFUNC
>        function ErrorCallee(toErr, tcprogram)
>        *-- will not be called often, but coded often
>             this.oErr = m.toErr
>             return .t.
>        endfunc
>		

as this presumes no errors happen, they will be set when coding for it and initializing with .t. is not needed at start.
>But that is complaining at highly personal style level (you may call me princess on a pea...)
>
>The rest: interesting combination of bindevent and This_access, making for very short and succinct code.
>I am sure I would never have coded it that way, but for wrong reasons: throwing together this_access plus bindevent are 2
>not to well known possibilities, this_acces having a warning note early in help file and bindevent getting some changes in vfp9 from 8.
>Chances of new versions are slim, so my "gut reasoning" does not hold true on that account ;-)
>
>Still, for accessing tables via COM I'd probably code a 2 parameter DoReplace(tcFieldname, tuValue) at first.
>Wanting the automatic replace to happen on property setting I'd probably write some code in .SetUp
>to read the table and generate corresponding class with _Assign methods, compile that and load it and
>add some more utility methods like checking if a fieldname is in the table.
>For GUI / Biz code your approach will show no difference,
>munging data I guess the _assign could be minimally faster at the cost of slower start.
>And your code will have less problems with existing property names, clearly a pro for you..
>
>Interesting approach and especially because of shortness saved here.
>
>regards
>
>thomas