Jim,

>"...how much code you are stuffing in them...". Why would this matter one iota? I mean, I can understand that locking 10 versus 10,000 records (i.e. "how much..." can matter for certain things, but for code itself I'm at a loss. And why would the code's existence in ACCESS/ASSIGN methods be any different than anywhere else?

It matters to those that complain about the performance hit the extra calls to assign are imposing on them. I prefer to keep my A/A methods short and sweet.

>Similarly, "...be concerned about side effects your code might have..." begs similar questions. ANY code can have 'side-effects' (e.g. CREATE TABLE leaves the table selected, SELECT SQL... INTO CURSOR leaves the cursor as the selected alias, etc. IF there happen to be "side-effects" to the usage of ACCESS/ASSIGN then they ought to be mentioned in documentation and any observations that do not conform to the docs ought to be categorized as a bug (doc or function) and NOT consigned to the 'be concerned about side-effects...' category.

It's an unexpected side effect that accessing form.Width triggers it's assign. The side effects you mention are expected. If it turns out that this is just the way it is then yes it needs to be documented and then it moves from the category of unexpected to expected side effect.