Hiya Erik ----

>
>This only seems scary now because we are not used to thinking in terms of Access and Assign methods. Once we learn to immediately recognize that accessing a method has the potential to fire code in that method's access event, it will become second nature to look there.
>
>You could say the same thing for validation rules and update triggers, and we have grown used to them (though I have to admit, sometimes it takes me a minute to figure out I need to be debugging trigger code).
>
>John, yes, these methods are godsends, but they don't really give us much we couldn't have before. If you wanted this functionality before you just discipline yourself to write and use get and set methods, and don't assign properties directly. A common example used for Assign methods is form.caption_assign. Well, if you created a form.setcaption() method and only use it to set the form's caption, you have just given yourself an 'assign' method.
>

This is all very true, but it is nice to have the language support, natively, for constructor, destructor, and now, accessor events. Plus, there are a boatload of uses for Access and Assign with distributed VFP DLLs and distributed classlibs, et al where you might want to hide the implementation from the developer's (not necessarily user) interface.

>The exceptions are a few properties that the users have direct access to, like form state. Otherwise, Access and assign are just ways to enforce discipline we could have always been enforcing on our selves.
>

Yup. True. I've had a Form.SetControls(cOnOff) for form nav controls since VFP3 beta.

>Don't get me wrong, I can't wait to integrate them into my framework, because they have the potential to make some things a lot simpler (form.lockscreen_assign will be the top of my list). Just wanted to point out that we can create most of this functionality already.

I'm intrigued. What are you going to do with LockScreen_Assign?