>>Getting away from the MessageBox() in particular. How about these four for accessing the registry: HKEY_CLASSES_ROOT, HKEY_LOCAL_MACHINE, HKEY_CURRENT_CONFIG, HKEY_CURRENT_USER? Again, without looking them up, what are those values? I was able to sit here and type these out without looking to see what they the key names were. The values? I don't have a clue.
>
>I store these values as protected properties of my registry access class, and never have to touch them outside the class.

And I would reason that you've created more work and maintenance for yourself than you need. Is there anything wrong with what you've done? No, but you've opened the possibility of have to go back and change it at some later time. Further, by not using the constants (which are pretty much universally recognized), you now have to remember the names of the properties and what they relate to. I'm old, my memory isn't what it used to be. The less the better (less chance of something else falling out< bg >).

>Taking the argument a step further, and playing the devil's advocate, another coding practice I hear preached, and that is, user messages do not belong on code, they belong in include files, or message tables. The reasoning is: if the app ever needs to serve another language, only values in the include file or messaging table need be changed. This is a great reason to practice this. But I don't, for a couple of reasons.
>
>Firstly, there is a 0% chance that most of my software will ever need to be used outside the US. The increased construction and maintenance time of removing all user messaging from the app is not worth it.

If the table isn't included in the EXE, but rather is provided separately, you reduce the size of the executable. These days that isn't really as much of argument as it used to be, but it can still impact. But you do indirectly reference the point I alluded to in my previous post. If you're the only one modifying the code (or the other circumstances don't apply), who cares how you do it as long as it works for you. However, in general, the argument that you allude to has merit, and should be aplied when the circumstances warrent it.

Several years ago, I thought the same way. There would be no chance that my applications would be used outside of the US. Then Shaw bought facilities in England and Australia. Whoops! The dates alone created additional a lot of maintenance.

>Secondly, often, a user gets a message from my application that doesn't explain a problem in terms they understand, or they get a message they don't think they should be getting. In either case, I need to get into my code to remember what causes the message, how it could be better worded, or whatever. Removing the message from the code makes it more difficult to locate the code. Also, user messaging in the code can serve as an additional code documentor. IOW, if I see a command at the top of a routine that says:
>
>WAIT WINDOW "Creating index files..." NOWAIT

>I know instantly what that routine is doing in the big picture. I don't even have to look at the comments.

Ah, comments! I've mentioned before that I had a professor who returned one of my assignments with the note: "Don't comment the obvious". If the code is self-documenting, then the need for comments is greatly reduced. And that's been one of my points here. The use of defined constants helps make your code self-documenting.

>Anyway, I know I have strayed way off the original subject, but I thought this was related...

Not much. This has been quite enjoyable.