>I put double quotes around fully a qualified name with
>spaces in the path, of course. But it appears that
>many (all?) of the file- or skeleton-related
>VFP commands produce the same result, with
>or without the quotes, e.g.,
>
>x = "\Program Files\MyFileName"
>y = ' "\Program Files\MyFileName" '
>FILE(x) = .T.
>FILE(y) = .T.
>
>When storing such values in a memvar,
>I've been including the double quotes,
>just to be sure. But what's the rule of
>thumb here? Are there any commands that are
>gotchas? (I've noticed, for example,
>that, with the above, ADDBS(y) produces
>a result with no quotes.) Am I always
>safe without quotes in a name expression?

Your example is simply using variables with functions such as FILE( ). You don't need the "y" type variable, your "x" example is fine. I'd actually expect your "y" construct to cause problems in some situations, because you're forcing the string to include double quotes, which are not part of the name of the file you're trying to access. It looks like your ADDBS( ) example is one of those.

It's worth noting that a "name expression" in VFP usually refers to something slightly different:

* Examples using the USE command:
USE \Program Files\MyFileName  && fails due to space in file name

USE "\Program Files\MyFileName"  && Works as expected

x = "\Program Files\MyFileName"

USE &x  && Macro expansion, fails because it is expanded to the same thing as the first test, then interpreted

USE x  && Fails, looking for a file named "x"
USE "x"  && Fails, looking for a file named "x"

USE EVALUATE( x ) && Fails, variable x not found
USE EVALUATE( "x" ) && Works as expected

USE ( x )  && Name expression, works as expected.
* Essentially the same as the second EVALUATE( ) test above