>Hi Ned,
>
>>I wonder if access/assign have any other "features" that we need to be aware of. Let me know if you find any.

<snip>

>Does this help?
Immensely, as it tells me that access/assign is still very much under construction by MSFT. Since you seem to have looked at this quite a bit, I'll run what I'm trying to do by you and hopefully you will see any potential pitfalls.

I have worked a bit with assigning object properties as control sources for UI components. It seems to work quite well. I saw the assign methods and thought that they might be useful for field level validations. They would serve much the same purpose as the rules in DBC's but without the DBC. This would make the rules for generic business objects such as addresses more portable. It would also open the possibility of subclassing the rules.

It seems reasonable that when data is read into the control source object by the app(as opposed to entered by the user through the UI) that all data validation rules should be bypassed. A flag property would handle this easily enough but I'm sure you see the catch. The object will have more than one property and it will take time to change them all. If the user is allowed to enter more data while the assign logic is running the results will depend on VFP's implementation. What you have told me suggests that the only way to prevent non-validated data from being assigned to object properties is to prevent any interruption of the assign code. This leads me to consider the AutoYield property. Hopefully, the consequences for ActiveX controls will not be too severe.

Thanks for the info. I look forward to your reply.

Ned