In programming, tracking a bug can be a tricky business, particularly if the user has not told the programmer or support team some vital information.
I found a bug! Or did I?
Before you post a bug report, make sure you actually have found a bug. Sometimes, you may not have activated a feature or perhaps the computer is having an "off" day. Test your "bug" a couple of times to make sure it wasn't a "once off".
OK it is a bug, now what?
Well now you can prepare a bug report. In this report it is important to convey all the important information to Dale and the support team in a clear manner. So this means don't use topic titles such as "BUG!", "This doesn't work" etc. Use an intelligent title which allows other forum readers to know what is actually in your topic without writing an essay for a title.
We have had discussions before about people coming onto the forum and just seeing the word BUG about 50 times in the forum message listing. Remember, until Dale investigates - it is not an official bug yet.
What should I say and how should I say it?
- Product name (e.g. DHPOS) and version (e.g. 5.02)
- List any specific settings (e.g. those as in POSCONFG) that you have set which may affect this error occuring. You don't need to tell us everything about how the program is configured, just the settings you feel might be connected to this error occuring.
- List the steps, preferably in a bulleted list, such as this - so that the programmer or support team can go through and easily reproduce the error. (e.g. I pressed the X key, and then Enter)
- If it isn't clear from your steps what the bug is, describe what goes wrong after carrying out the steps you listed. (e.g. the program closes with a file access violation error in line 3)
That's it - easy isn't it?
![Cool 8)](./images/smilies/icon_cool.gif)
An idea which just occured to me is perhaps the CRNC news site will have a page where you can type all this in, then it puts it into the correct format (as described above) for you to copy and paste onto the forum.