Hi Roi,
>
>It's funny, this weekend I had the same thought as Mark, why not just give nice meanful names to all those sys()'s and drop them in a sys.h file and be done with. I was actually suprised someone hadn't already done it.

As long as you realize the consequences of doing so, there's nothing wrong with it. I do believe that this subject (making SYS() functions more readable) has been touched on before in this vein..

>So I've been following this thread waiting to see if it was a silly idea.

Not at all. I does overcome the problem of keeping all those #$%@^&* SYS() functions straight. However, I'd be more inclined to wrap them in UDF's simply because we don't know if this "feature" might someday be "fixed" (or broken depending on your POV).

>As I am new to constants your post was nice as it confirmed what I had already surmised about how they work.
>
>However, I don't know that I agree with your reasons for not doing it. I don't think the behaviour is inconsistent, the compiler replaces all the constants and compiles the code, there is no evaluation going on is there? Do other parts of the code get evaluated at compile time? I've only started to work with compiled programs so I don't know the answer.
>
>Also, I just looked through a bunch of .h files that come with VFP and there are plenty of places where chr() is used in the constants. See _help.h:
>

#DEFINE TAB			CHR(9)
>#DEFINE LF			CHR(10)
>#DEFINE CR			CHR(13)
>#DEFINE CR_LF		CR+LF
>#DEFINE	EVAL_ITEM	CHR(0)+"_"+CHR(255)

>What is the difference between CHR(13) and SYS(5)?

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!

>Isn't this the same thing. I think if MS ever decides to change the behaviour to evaluate the constant as opposed to just replacing it won't that result in every constant being evaluated?
>All of sudden all those MB_ICONSTOP's become eval(16) instead of just 16.

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.

>Besides I always think of constants as the opposite of variables. A variables value can change, a contants value never changes. In Mark's case the constant just happens to be an expression that gets evaluated at run-time.

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).

>As I said I've just starting working with constants and am looking forward to your thoughts.
>
Hope I didn't disappoint< g >.