Ok, that was the best explanation yet, but I guess it does come down for the most part to code practices. The hard part is that a lot of the code I work with seems to have a mixture of both, for what now seems like all the wrong reasons.

>To reiterate what others have stated already, #DEFINE values are replaced during compile-time. Essentially the compiled code will behave as if you put the constant in the location specified. So:
>

#DEFINE FOO 100
>#DEFINE BAR I
>FOR I=1 TO FOO
>  ? BAR
>ENDFOR

>compiles to the *same* result as:
>

FOR I=1 TO 100
>  ? I
>ENDFOR

>
>As to why would one use as #DEFINE instead of a simple variable? These were already addressed:
>* #DEFINE don't require allocation of memory for a variable. You end up with more variables within the common variable pool -- which has often been limited in size.
>* #DEFINEs essentially act as a conveninent way of supply constant values that you can centralize in one location. Symbolic names make a lot more sense than numeric values you have scattered within your code. For example, look at the difference it would make between:
>

>nAns = MESSAGEBOX("Some message",2+48+512,"The title")
>DO CASE
>  CASE nAns = 2
>    * blah, blah
>  CASE nAns = 3
>    * blah, blah
>  CASE nAns = 4
>    * blah, blah
>  OTHERWISE
>    * blah, blah
>ENDCASE
>

>vs
>

>nAns = MESSAGEBOX("Some message",MB_ABORTRETRYIGNORE+MB_ICONEXCLAMATION+MB_DEFBUTTON3,"The title")
>DO CASE
>  CASE nAns = IDCANCEL
>    * blah, blah
>  CASE nAns = IDABORT
>    * blah, blah
>  CASE nAns = IDRETRY
>    * blah, blah
>  OTHERWISE
>    * blah, blah
>ENDCASE
>

>* Variables can get changed -- many things set up as #DEFINEs are values that should never change -- things such as numeric mask values used for MESSAGEBOX(), FOPEN(), etc. Hard-to-track bugs result "when variables don't (vary) and constants that aren't (constant)".
>* You'll need to make these "constant" variables global variables -- something that should generally be avoided unless absolutely necessary. However statements like PUBLIC and LOCAL will mess that up completely, as it allows for the meanings of these constants to change.
>
>* One might argue that the fact that following doesn't yield a syntax error would disprove the claim that #DEFINEs are replaced during compile-time:
>

#DEFINE FOO 10
>FOO=15

>the above code *doesn't* generate a compile-time error. However you will find out that you don't get a compile-time error with the following as well:
>

10=15

>(i.e. in both of these cases the syntax error is spotted at run-time, not compile-time)