Hi Ned,
>Immensely, as it tells me that access/assign is still very much under construction by MSFT.

That's my impression, too. It's a really cool new feature in version 1.0.

>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.

I did something similar, but used the assign method for conversion. For example, I have a data field where the user can enter a date, or any string like "today", "tomorrow", etc. It's also great for data objects.

>If the user is allowed to enter more data while the assign logic is running the results will depend on VFP's implementation.

And that's the point. An assign method can be interrupted and thereby the assign method might be bypassed. But this can't happen always. It happens with VFP intermediate interruption commands like all ON... commands. It happens whenever you force input processing via DOEVENTS or maybe via WAIT WINDOW or Inkey(). In the latter cases a timer might fire. And it happens with ActiveX controls.

It doesn't happen with VFP controls because while VFP executes a method it doesn't process any input event. So even when it's a lot of work, it's not undoable if you are carefully not to fire assign methods within a timer, an ON method or any other event that might occur inbetween. You shouldn't call Requery() or Refresh() methods from within such an assign method, neither Move(), and other method that would fire events.

>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.

You get a high level of security if you assign the new value to the property in the very last line. This would override any wrongly assigned value that happened inbetween.

Christof