>>I think were hoping that the constant will be replaced with the SYS functions but not evaluate the sys functions. Tests seem to bare that out. Though it would be nice to be able to look at those constants in the debugger and verify that.
>
>Hi Dan,
>
>Well, I did something unthinkable...I RTFM< g >. While the documentation states that creation of the constant occurs at compile time, I think that something else it says probably applies. "Important Do not use system variables for eExpression. System variables are not evaluated until run time." I have a feeling that creating a constant using native functions causes the interpreter to execute whatever code is associated with the constant at run-time. To test this, I created the following little program

* Test.h
>#DEFINE DEFAULT_PATH SYS(5) + SYS(2003)
>* Main progam.
>#INCLUDE TEST.H
>_SCREEN.Visible = .F.
>LOCAL lcmsg
>SET PATH TO
>lcmsg = "Current path is " + DEFAULT_PATH
>= MESSAGEBOX(lcmsg)
>SET DEFAULT TO C:\FOX
>lcmsg = "Current path is " + DEFAULT_PATH
>= MESSAGEBOX(lcmsg)

>The first message box displayed the exe's startup directory. The second displayed C:\FOX. From these results, I'd say my conclusion is correct.
>
>As far as getting the debugger to recognize compile time constants, I can see the benefit, but I never really worry about what the underlying value is. One of the things that compile time constants are supposed to do is abstract more complex values so that we don't have to worry about the actual value, just the name. In my mind they're somewhat akin to assembly language mnemonics. Just my take, of course.

I always thought the F stood for .... Filthy. I was testing datetime and that changed every time I ran the fxp. There have been times, when debugging, and trying to trace down a problem that, you get to the point where all the variables look fine and what about this kcBadFileErrorMessageLine. Place it in the debugger and of course nothing. I think its more a matter of convenience. I think that VB allows you to look at the constants.