>>Here is a Bitmap with what I think is hard cold evidence of this (it shows the Locals window and Trace window; take not of the value of the combo "Locals for"): http://208.230.170.137/mgh/jimb.bmp
>>
>>How would you argue against that?
>
>Mike,
>
>I believe we are saying the same thing. A variable has two properties in this area, visibility and scope. Scope defines the lifetime of the variable and visibility defines what routines can address the variable.
>
>

><strong>Var Type         Visibility       Scope</strong>
>PUBLIC                Everywhere        Creation to release or quit VFP
>PRIVATE               Creator and below Creation to Release or creator ends
>LOCAL                 Creator only      Creation to Release or creator ends
>

Some refinements:

(1) Variables are not in scope under their original name if passed by reference. This includes PUBLICs. PUBLICs and PRIVATEs passed by reference as LPARAMETERS are completely invisible to processes called by the block of code containing the LPARAMETER declaration. This can lead to much head-scratching where different instances of objects have different scopes. Bottom line - don't pass PRIVATEs or PUBLICs where they might be expected to be seen with their original name.

(2) Variables go out-of-scope if a called procedure explicitly declares the same name as PRIVATE or LOCAL, or if the name is declared in a called procedure as PARAMETERS or LPARAMETERS.

(3) Variables of all types may be hidden by masked name declarations in PRIVATE statements that reference a skeleton (PRIVATE ALL LIKE/EXCEPT) without the variable being created. If a variable is masked by such a skeleton, it is hidden to all procedures below the masked PRIVATE declaration. PUBLIC declarations for PUBLIC variables hidden beneath such a mask have odd and unpredictable side effects after the mask disappears. Bottom line - masked PRIVATE declarations can cause problems.