>>>>>>>Jim I shouldn't need to tell you that's completetly diferent,
>>>>>>>The #DEFINE will be on a single file easy to maintain while the variable would have to be all over the place unless u create it as public and we don't want that do we?
>>>>>>>take care.
>>>>>>
>>>>>>How many routines do YOU have in your app that checks for a disk in a drive??
>>>>>
>>>>>I thought this intere conversation wasn't cause 1 routine, was cause of #DEFINE versus Variables.
>>>>
>>>>Alexandre, it is no attack. :)
>>>>
>>>>The point I tried to make is that a variable will do as well, and in my opinion even better, if it is a text/value that is used only in one place. The example Jim Nelson reflected upon is a clear example of a text that is used in one routine rather than in many. If that text would occur in many routines, then the developer should reconsider the modularity of his code, rather than the variables-versus-constants debate.
>>>
>>>You're not nit-picking over the choice of message example, are you. That's not the point; it just happened to be the first example to come to my head, rather than spend half an hour thinking up a "real-life" example.
>>
>>Terry, I'm glad you came up with exactly *this* one! Because it clearly demonstrates the point I made. Of course, another example would demonstrate your point perfectly. :)
>
>Peter, who's to say there wouldn't be a system where this message appears in several places anyway? But, like you illustrate, I wouldn't DEFINE it myself if it was only to be used once. Similar to Jim's objection, if I've a big (unique) err mess in a prcedure/method, I tend to define the text as a memvar and subs. the memvar in the messagebox.

Sure, the messagebox may appear in many places. But all those places should call the one and only UDF that shows the message. And it is in that one and only UDF that the text is declared, so one time only.