>>I think Codemine's data layer is its *best* feature.
>
>yes, I agree its very good - _as long as_ you do it the CM way ;-)

OK. But isn't this why you buy into the framework?

>use a control's Valid instead of afterchange/validatefield

The original question was querying how separated you were from VFP (I think <s>). If you take something like VPM, you use its own idiosyncratic interface and builders and data-dictionary. I am not bashing VPM - it has very many enthusiastic followers. I am implying that this is the kind of framework (maybe Fox Express too) that gets between the developer and the Fox to a greater degree than Codemine would.

On this occasion, the CM data controls are optimised to run with its own data layer. The point is that you are not abstracted away from VFP in any way. If you really must use a control's native valid directly, you can always drop a standard VFP textbox on your form, set its control source and your away. Codemine will be quite happy for you to do this.

Why would you want to use a control's native Valid event when the framework provides a subclassed (and enhanced) "fieldvalid" method both at the control and rule level?

>set a value / property directly instead of using set / setvalue ...

Because you are using controls that support very enhanced binding capabilities, the use of the methods you refer to (Set/SetValue) ensure that other (required) CM properties are correctly updated. For example, why use Codemine's Replace method and not the VFP native Replace command? Because Codemine's replace ensures that certain other/additional rules are fired, just like you had entered data from the interface. If you don't buy into the methodology of the framework, then you either roll your own or just use VFP as-is. Either way, the examples you cite merely ensure that the integrity of the framework is not breached.

Best