by GeoffA | categories General comments | all news items

With any complex software, especially that under active development, there will be bugs of various types.  In this article we will briefly state:

Bug policy

We hate bugs and are quite sure that you do too.  We aim to resolve bugs as soon as we know about them - either from our own work or from users. Ideally we will aim to correct a bug the same day that we hear of it - though sometimes that is impossible, because of resources or because the bug itself is difficult to resolve. Once resolved, the afflicted user will get an update asap.  This correction will then be rolled into the next official update within the next week or so, so that other user may benefit from the work. If you look at the page for the relevant software, underneath the video clips list, you will see a version list with notes on bugs resolved and features added.

Types of bug

Lets start by categorising bugs:

  • Cosmetic bugs - problem in appearance.  spelling mistakes/misalignments of controls etc
  • Compilation bugs - problem in our code.  normally caught by error trapping, but sometimes causes a complete crash.  This may be things like a division by zero, or subscript out of bounds
  • Programming language bugs - problem in the language. occasionally we find an error occurs not because of anything we have done, but because of a problem in the programming language.  Language updates from microsoft are infrequent, so a work around will have to be found.
  • Theory errors - problem in the results. The data calculated by one of the programs is not correct for a certain situation.
  • Misunderstanding - problem in your expectation. Maybe you have been expecting the program to behave in one way, when it behaves in another way which is actually correct.

Having categorised the bugs, we then move on to solving the problem, but before we can find a solution we have to find the cause on our development systems.  And to find the cause, we must be able to replicate the problem ourselves.  Sometimes this is very straightforward and sometimes this is very difficult.  We can categorise bugs in a different way for this:

  • Bug reproducible on demand
  • Bug occasionally seen
  • Bug on user computer only - these are nastiest of all. 

The first two kinds of bug can usually br resolved quickly - the third kind may require the use of instrumented versions to debug the problem remotely - a time consuming process.

Reporting bugs

More is better!  Please don’t just say ‘WinLens3D crashes’ or ‘WinLens3D is wrong’!  Be as detailed as possible! As a minimum we need to know:

  • What happens - what are the incorrect results
  • What error messages [if any] are displayed
  • When does it happen - what sequence of events causes the problem
  • What file are you working with - please include this - we will treat this as commercially confidential.

Screen captures are very useful, especially if you annotate them clearly - remember one picture is worth a thousand words!

You may even wish to consider making a small video screen capture.  We have found that Jing from Techsmith [makers of the Camtasia video recording suite] is great for this purpose.  It’s free, fun and simple to use, and you can add a voice over at the time of recording, so you can show and explain the bug in one quick go.  Once completed, the clip is uploaded by Jing, and you are given a simple url which you can paste into an email.

Click this link to REPORT A BUG by email.  On this site we normally offer a contact simple form, but in this case, your email client will be loaded, so that you can add relevant attachments, e.g. lens files, graphics etc, if so desired.



prev MachVis 3.0 released .. next.. MachVis 3.5 is coming!

Social site bookmarking