A: Dealing with errors is not an easy thing to do in an application. There's no Holy Grail, no single solution that fits every application. Many contradicting aspects need to be balanced. Even the law can be an issue. Let's look at a few issues before I present an error dialog with a feedback option.

The first question you need to answer is who the audience for the error message is. Most users gain very little from error dialogs. Typically, they print and send them to you, or they use them to recognize known bugs they can safely ignore. They rarely help users to fix the problem, though. A "file not found" error when printing a report might tell you that a report file is missing. For most users, this message isn't any different from the stack dump messages we see when VFP crashes.

Many applications therefore provide only simplified error messages stating that an error has occurred without going into any detail. Advanced users benefit from some messages if they can fix them with simple configuration steps. Anything beyond that is usually only interesting to administrators, developers and hackers.

This raises the next issue that needs balancing. If your users send bug reports at all, what you frequently get is a screen shot of the error dialog put into a Word document or sent as a fax. They don't tell you what they did, they don't send any of the log files your application might create, nothing. Hence, many developers try to put sufficient information into the dialog, not for the user, but for the developer who gets the screen shot.

While this helps the developer in fixing the problem, it confuses the user and provides information to unauthorized people. If you are a hacker that wants to obtain source code or data, it's always helpful to have as much information as possible. For example, you can use the report designer to open any VCX file that's included in the EXE. However, you need to know the precise name of the VCX library. An error message reveals this missing piece.