Erik,
I agree with your thoughts, 99%. The only exception is the one I use :-), my forms (complicated ones) carry 'primary_key' property which is already abstract entity, so applying Assign (so far, I don't use Access) method on it, makes this abstraction more complete, so I like it. Again, I totally agree with you that free usage of Access/Assign will create loosened design and compromise code read- and maintainability.

>John K, Arnon G., and Nick N and I had a long debate over Access and Assign over beers by the pool at DevCon. Everybody disagreed with me on my (apparently unpopular) stance. Here is my take:
>
>The _ONLY_ thing that Access and Assign give us that we did not have before is the ability to run code when the value of a stock VFP property (not a custom property) changes. As a matter of fact, IMHO, use of Access and Assign methods can be considered bad design in all but a few cases. Here's why.
>
>Following loosely with the example given, let's say I have a DE form class in which I want to place some generic code to disable/ enable controls based on a "mode". The two basic design alternatives are
>
>1. Create a form property called "editmode" or something, and make the property available to the form instance, running code in the Editmode_Assign method to change the controls. Putting the form in "add" mode might go something like:
>
>THISFORM.EditMode = "add"
>
>2. Create a form method called "SetMode" that sets a hidden form property based on the parameter sent, and then running the enable/disable code. Putting the form in "add" mode might go something like:
>
>THISFORM.SetMode("add")
>
>I believe that alternative 2 is preferrable for a couple of reasons. First, (and most importantly) the calling object (or programmer) knows by his syntax that he is causing code to run by changing the mode of the form. That's what a method does: run code. In the first example, the developer or calling object sets a property and may have no idea that he just caused a long chain of events to fire.
>
>In an Assign method, the method has the power to change the value of the property that s being assigned. Therefore, the following scenario is possible (and in many cases likely, if the code that puts a form in edit mode denies the mode on certain conditions):
>
>THISFORM.EditMode = "add"
>?THISFORM.EditMode && returns "none"
>
>With a Get/Set method pair (as in my second alternative) is used, the method can return a value on success:
>
>IF THISFORM.SetMode("Add")
>*Continue processing here only if form was successfully placed in add mode
>ENDIF
>
>IOW, I feel that Access and Assign methods make the interface for an object unnecessarily deceptive, without any gain in ease of use. For any custom property you can implement Get/Set method pairs to deal with access to the property that can be used just as easily as a property with _Access and _Assign methods.
>
>It was often stated with the intrduction of Access and Assign methods that we finally have a "clean" way to do these things. BS! If you had the discipline to create your classes correctly, and hide internal properties through the use of Get/Set pairs, oyu always had this ability.
>
>I want to loudly place my only exception here: stock VFP properties. We cannot protect or hide VFP propreties such as Form.Caption and Form.WindowState. Often, the only way to cleanly implement code that runs when these propoerties are set is with Access and Assign methods.
>
>In sum: A/A is bad in most cases, because it allows a developers to buld a tricky/ non-intuitive interface.
>
>>Could I give one?
>>Let say you create custom property Thisform.KeyValue and use its Assign method to make all operations to 'refresh' a form. So now any time you really want to 'refresh' a form, e.g. from cmdNext/Prev click event, or just revisiting the form after search dialog, or after new record added, or after record has been edited: any time you just issue one line of code:
>>Thisform.Keyvalue=MasterTable.Primarykeyfield
>>and even if you are still on the same record everything will get refreshed.
>>Obviously, this example is not for 'dumb' Thisform.Refresh functionality, but in more complicated interface it works great. Personally, I've perceived 'Assign' method as the missing chain in my preferable way to develop, because I already used 'KeyValue' property in VFP5.
>>
>>>Could you go into more detail with this example? I haven't found a use for access and assign methods yet.
>>>
>>>>I don't know whether this has already been covered but I found that a great place to put form behavior code is in the assign method for a property. I usually have a property called ladding on my forms to indicate that we are adding a record, I now put all my control (vcr buttons etc) display code in the assign method and test the status of the property within this method.
>>>>
>>>>Hope this may be of use to some.