>Is there an advantage to using:
>LOCAL lcVariableName1, lcVariableName2, lcVariableName3
>vs.:
>PRIVATE ALL LIKE l*
>?
>
>I assume that compiler/run-time speed is an issue when private all like is used. However, private all like cuts coding time and variable management efforts considerably.
>
>How much speed loss with the private all like method are we talking about. And does it matter with today's fast computer systems?

In VFP 3.0 I found that debugging was made difficult by use of LOCAL, but this problem seems to have gone away in VFP 5.0, so I would definitely favor using LOCAL unless you have a deliberate reason to do otherwise. I.e. if you want to make a variable directly visible (and modifyable) by a called program. LOCAL is safest, and I doubt that the performance difference would be perceptible.

I especially avoid PRIVATE ALL, because I've gotten burned with that in the past. Where it can cause a problem is in the use of menus that contain SKIP FOR ... clauses involving memory variables that were supposed to be well defined, but they become undefined if one of these PRIVATE ALL routines happens to be invoked at the wrong time. Then you start getting these "variable not defined" errors as the menu is repainting itself.

I remember noting some gimmickery mentioned somewhere in the VFP help about how certain Wizards can cause such problems unless you follow a certain naming convention for variables that may be referenced in your menus. This is because those Wizard apps. use PRIVATE ALL EXCEPT ... something that matches this reserved naming convention. Yuck!