>>Believe me, it left me scratching mine when I first saw it, and yes, it goes against everything I thought I knew about compile time constants. If I were to hazard a SWAG, it looks like if a function call is used, we've got our old macro business going on. If literals are used, then I'd suspect they're treated like any other (normal) compile time constant.
>
>The way I explain it to other programmers is, just imagine putting the value of the Constant in the procedure where its found. Basically doing a STRTRAN() on your PRG.
>
>#DEFINE cdDATETIME datetime()
>?cdDATETIME
>wait window timeout 5
>?cdDATETIME
>
>Should give you two different times because when the code is compiled the "cdDATETIME" is replaced with "datetime()" and you get:
>
>?datetime()
>wait window timeout 5
>?datetime()

Since it's evaluated at runtime, depending on the circumstance, you may be far better off using a varible rather than a constant. For example, assume that you've got a large number of lines you wish to output to a text file that you've got to add the carriage return/line feed pair to. Rather than #DEFINE CF_TEXT CHR(13) + CHR(10), you're better off with lcCF_Text = CHR(13) + CHR(10) because the function calls will only occur once.