Hi George,

>As long as you realize the consequences of doing so,

Good advice for anything, including wind direction during spitting < g >.

>As Dan pointed SYS(5) won't always return the same value CHR(10) will. In fact, the only way I could create a string simulating an RGBQUAD array for 256 colors for Obj2Bmp was to create a header file for it (too many characters otherwise). Now I realize that this header file is being evaluated at runtime. Phooey!

Right SYS(5) doesn't return the same value but I was thinking of it this way,
APP_CURRENT_DRIVE's value is contantly SYS(5)

>Nope. I'm a bit cloudy on what the technical details would be in the case of VFP. In other languages creating a compiled constant doesn't replace every instance of it in the executable but simply a reference to it. Using a literal, however, causes the compile to insert that, which tends to use up more space.

Just looked in the VFP manual under #DEFINE ... #UNDEF Preprocessor Directive'

To create a constant with #DEFINE, specify the constant's name with ConstantName and its value with eExpression. When the program is compiled, text substitution is performed and the constant value expression is substituted for the constant name wherever it appears in the program. You can stop the substitution for the constant by issuing #UNDEF.

>But it will also change if, for example, the default directory changes. If you read my earlier post, that's exactly what happens. Each time the "constant" is evaluated, it's actually re-evaluating the SYS(5) + SYS(2003).

Right I saw the ealier post but the CONSTANT isn't evaluated, it's value is evaluated.

I noticed that behaviour a couple weeks ago when compiling an app. There was an error in a line of code that had a constant in it. The error the compiler showed didn't have CONSTANT name but it's value.

>Hope I didn't disappoint< g >.

Never, thanks.