>>>Could someone educate me as to why it is standard practice to define constants with a variable name rather than to just use the constant in the code?
>>>
>>>IE, why is:
>>>

>>>#define MY_CONSTANT "My constant"
>>>? MY_CONSTANT
>>>

>>>better than
>>>

>>>? "My constant"
>>>

>>>
>>>I understand that it may make it easier to change the value of the constant if the need arises during design, but if the constant is only used in one place in the application is there still an advantage?
>>>
>>>Thanks for any enlightenment.
>>
>>Another example:
>>
>>You have a 3-line error message that you need to put in a call TO MESSAGEBOX(). Insted of writing a space-consuming, messy MESSAGEBOX message you could just include, say, ERR_MESS_NO_MEDIA. ERR_MESS_NEED_REBOOT, etc.
>
>And in these days of 128 character variable names all that looks like extra work for very little gian (if any).
>In general my view is that #DEFINEs are more trouble than they're worth.

I disagree with you. The second of the 2 below (fictitious) messages is easier to follow and understand, and takeds up less real-estate.
This is esp. so if, say, it appeared in the middle of a much-indented piece of code and had to be broken up over more lines still, with all the problems of putting in the CHR(13)s, matching parenthises, etc. Also, MB_ICONSTOP is much easier to understand than just 16, esp. if there were other button-icon permutations to consider.
OTOH, of course, if this were to appear just once in the suite then it would be more trouble than worth. However, if at a later date it were found to be needed again, then the trouble is vindicated.

= MESSAGEBOX( "There is no disk in the selected drive.  Please ensure that there is a disk in the drive" + CHR(13) + ;
              "reselect the 'Save Changes' Checkbox and click 'Execute' again.  The process will continue" + CHR(13) + ;
              "from where you left off", 16, "No Disk in Drive")

= MESSAGEBOX( ERR_MESS_NO_DISK, MB_ICONSTOP, "No Disk in Drive")

You surprise me, Jim.