Hi George,

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.

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

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

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.

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.

As I said I've just starting working with constants and am looking forward to your thoughts.

>
>I've got really mixed feelings about this one. I understand, however, that this is what you want. I'm not terribly sure, though, that it's a very good idea. Let me explain.
>
>For anyone new to what compile time constants are and why we use them, let's first go over that. By creating them you reduce memory consumption, increase performance and, make your programs easier to read, and thus, maintain. The most important thing to remember here is that this is supposed to be a constant.
>
>While on the one hand it does make it easier to read CURRENT_DEFAULT_PATH, than SYS(5) + SYS(2003), it is exactly what it says, because it is re-evaluated whenever it's referenced. It's more like a system variable rather than compile time constant. That bothers me, and perhaps it should bother you too. Consider...
>
>What if MS decides that this behavior, strictly because it's inconsistent with the intended, is a bug and fix it later? Whoops! All of a sudden you've got a very difficult to track down bug. All those references to CURRENT_DEFAULT_PATH, are actually references to COMPILE_TIME_DEFAULT_PATH.
>
>Anyway, that's my take.