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.

Proper class design dictates that these methods be hidden from the user anyway, and only exposed through get and set methods, if code must be run when they are set and got.

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

Often in a nested refresh situation, containers want to set lockscreen while they refresh, and unlock when they are finished, so the need for a sort of multi-level lockscreen is needed. This can be handled by keeping track of what object set the lockscreen and how many nested objects need the screen locked so when an object finishes refreshing, it merely notifies the controller that _it_ is finished rather than completely unlocking it, if it did not have the authority to do so.

Codebook uses a similar approach to handling lock screen.