Good Bug Reports

Bugs happen.  It doesn’t matter how much experience you have, or how much you test your code, a user will do something that you didn’t expect and your application behaves improperly.  Perhaps it throws an exception and reports it to the user and continues working.  Maybe your application quits on exceptions.  Either way, you have an unhappy customer that is reporting back to you.

“It’s crashing,” is a common phrase I hear in the Xojo forums and from our own users.  So the first question I usually have is “is it really crashing or is the application reporting an exception?”  The difference being, of course, one is controlled by me and the other is the application goes *poof* and there’s nothing controlled about it.  With the former I usually have some data that can help me figure out what’s going on and the second is a bad sign that it might be a plugin or library issue that I’ll have to track down.

What is their operating system and version?  

It’s important to know if they are running on Mac, Windows, or Linux and what version it is.  For Windows and Linux it’s important to know if it’s 32-bit or 64-bit.  You may end up having to send them instructions to determine what version they’re running depending on the end-users skill level.

What version of the Application/Library/Control are they using?

Applications are relatively easy to get version numbers from since the user can get this from multiple locations (usually).  Controls and libraries are a different matter and you, as the developer, should make this easy to find with documentation and constants in the code.

We’ve all had an email where a disgruntled customer says, “It doesn’t work!”  If you have multiple products this makes for an awkward return email asking which product they’re actually talking about.

Can they replicate the problem?  If so, what are the steps?

Customers often think that simply telling you about a problem is good enough.  Sometimes it is but usually I need more information.  The more detail the better.  If it’s a sequence issue I will sometimes ask for a video showing it in action.

Can they send you the error log?

If you create error logs it is helpful to get those.  To get the error Stack of an exception is useful and can sometimes tell you exactly what to fix if you’re lucky (especially with small/short methods!).

You may have to tell the user not only where they are but how to get the location.  Getting to the Application Support folder on Mac and Windows isn’t hard but it’s also not easy.  On MacOS the users Library folder is invisible by default.  On Windows this location is buried multiple layers deep.

Can they send you an example project or file?

With developer products it’s handy to get a small example project demonstrating the issue.  I can’t tell you how often simply asking for this solves the problem because they find their own mistake.  Even if it doesn’t you now have a good example project demonstrating an issue you didn’t know about!

With applications and utilities getting their data file is good.  There is nothing like working with real data to discover issues.

Users aren’t often helpful when it comes to asking for help with your products.  What other things do you ask customers when dealing with bugs?

Debugging Your Xojo Applications

Your customers and clients expect your Xojo applications to be as bug free as possible.  What mechanisms do you have in place to handle an error and report it?  Bugs occur – that’s a fact of life – and even the best error handling in the world can’t prevent bugs from occurring.

Thoroughly testing your application is your first and best line of defense.  However, it’s very time consuming and without good testing procedures it may even be a waste of time.  I would also add the it’s very hard for the developer to be a good tester of their own code.  You programmed it to do a certain task in a certain way.  Someone else will have a different set of expectations.

Regression testing is the only way to really make sure that changes in one part of your code doesn’t change other parts of your application (or a new version of Xojo doesn’t affect you either!).  An excellent way to do regression testing on your software is to use the open source unit testing module called XojoUnit (it’s now part of Xojo).  It allows you to test your code with known inputs and test them against the actual output.

A common question from the forums is that people get an error message saying, “The application has encountered an error and must now shutdown,” and they have no idea what the error is or where the error happened.  They need to learn as much as they can about the Exception class and in particular the Stack property.  The stack was introduced way back in 2006 and is a string array that contains the methods that have run from the entry point into your code until where the exception occurred.  Be aware that the Include Function Names property has to be true in your application for the stack to be human readable.

Use the UnhandledException event in the application class to capture any errors that weren’t handled elsewhere.  The exception stack allows you to determine where the error occurred and from there it’s a simple matter to send an email, post to a web form or write the error out to a log file that includes important details such as platform, operating system version and the version of your application.

Some applications will require files be in a specific location and when debugging your application those files might not be in the proper (final) location.  Use the DebugBuild constant along with conditional compilation, #If,  to handle things differently at debug time and runtime.  For debugging purposes you can have the required files in the local project directory for convenience sake.  A feature added in 2007 allows you to place your debug build in a particular location which eliminates the need to have non-project files in your project directory.

Cross-platform applications require additional handling but now that Xojo with (or without) a desktop license can do remote debugging and it’s very easy to do.  I run the Xojo IDE on Mac OS X on an iMac and use VMWare running various versions of Windows and Linux so I can debug my applications in those environments.  The remote debugger works exactly like the regular debugger except that the debug application is running in another environment.  It’s a little slower to initiate since the app has to be transferred to the other environment but otherwise it’s the same process.

I highly recommend testing early and often on the other platforms you’re developing for.  Don’t wait until the end to do extensive testing.  While Xojo does a great job on cross-platform applications there ARE platform differences you need to be aware of.

New developers coming from Visual Basic 6 are often irritated by the perceived lack of database error in Xojo.  An incorrect SQL statement when opening a recordset results in nil recordset objects instead of a throwing a runtime error.  The unexpected nil recordset then causes NilObjectException errors.  You must get in the habit of checking your database object for errors after every database operation.  Once you catch the error you can at least be more graceful on how to recover from it.

That’s a lot of information so do your research.  Debugging your application isn’t as hard as you think.

What things do you do to make your life easier hunting down or preventing bugs?

Bat Shit Crazy Fix

Every now and then the Xojo IDE/compiler does something that just makes zero logical sense.  By all accounts some bit of code should work.  But it doesn’t and no amount of debugging and code changes solves it.  It’s easy to spend hours and hours chasing these bugs

Most times when something like this happens a simple Xojo restart fixes it.  But not always.

After that, I delete the Xojo cache files and restart Xojo.  Most of the time that will fix it.  But not always.

So I came up with the “If you think you are bat shit crazy fix”.  Do all of the above and simply restart your machine.  This has always fixed those situations.

Fine, call me bat shit crazy but I have at least 3 other developers that can attest that this works.  After hours and hours of trying to debug an issue I was out of options and that was the my last bit of advice.  Guess what?  Their problem mysteriously disappeared.

I have no idea what the problem is or even how to report it to Xojo.  All I know is that if I’ve exhausted everything else in my arsenal, the clear cache and restart seems to work.  Who’s crazy now?

RB Code Reports Version 3.0

Lenexa, KS, USA (August 10, 2012) – BKeeney Software has announced the release of version 3 of RB Code Reports.  RB Code Reports is a utility designed to read Real Studio binary and xml project files and analyze them and report on a number of useful things.  These reports are designed to let developers know of potential issues in their code.

RB Code Reports features the following capabilities:

– A statistics report showing how many lines of code and the code and comment densities

– An optimizations report offering ways to speed up code and avoid hard to maintain code

– A warnings report showing potential problems

– A signature report to document method signatures and to pull comments from methods

– A spelling report to show possible misspellings in control captions and other user interface elements

– A custom report option allowing the user to iterate the project tree and create their own report based on their own criteria

 

The following features were added in version 3:

– Can now read binary (rbp) project files

– Now recognizes Web Edition objects

– New optimization tests, include heavy use of variants, too many controls on a Window or WebPage

– New warning tests including the ability to check database code for sql operations that do not include a check for database errors, a very common problem with new Real Studio developers

– New signature report options to either pull all comments, or user selectable tagged comments, out of each method

– New user interface

– More preference options

– Automatic application updates

 

The pricing for this software is $24.95 for new users and $9.95 for existing owners of version 1.x or version 2.x

 

RB Code Reports can be downloaded from…

http://www.bkeeney.com/products/rb-code-reports 

For more information visit http://www.bkeeney.com or send email to info@bkeeney.com.

 

Serial Control in Windows 7 – Part Deux

The Serial communications saga continues…. Never say die when it comes to serial communications because, like so many things in programming, there are multiple areas where the problem might lie.

Here are the facts as I knew them this morning.  Given a hardware configuration (serial port to fiber optic converter to fiber optic converter to Serial to USB converter), I could reliably talk to my device in Mac OS X and Windows XP.  In Vista and Windows 7 it failed.  The serial port monitor software that I running in Windows was able to see the messages with 100% accuracy while the RB serial control was not.

Sounds like an RB bug, right?  I submitted it, with video proof, and had a reasonably happy weekend.  The client was not happy, understandably, and after consulting with REAL Software (who, by the way, responded to my email promptly this morning) agreed that it might be a bug and they would be happy to try to reproduce (and ultimately fix it) if we sent them the hardware and a sample program and some money to do it for the R4 release.  R4 will come out sometime this fall, by the way.

The client was not happy about the additional cost and the time delay as you can understandably imagine.  So I said I’d do some research and figure out if other people are having serial issues too before issuing a recommendation to send all the materials to RS.  I’m sure some of you are guessing where this is going.

It just so happens that the specific manufacturer of the Serial to USB Converter (Prolific) has some serious issues with their Windows 7 (and Vista) drivers.  After a few more specific web searches I found an alternative (perhaps older) driver that works fine if you do the following in Windows 7:  Right click on the properties of the installer, select Run as Administrator and select Vista SP2 under the compatibility popup.

Run the installer, restart Windows 7 and Voila!  We now have a fully functioning driver – that works – in Windows 7.

Hindsight, as they say, is always 20/20 and I *should* have thought about this last week.  I had “something in the middle” that I assumed worked.  I had evidence that it did work (the serial port monitor) but my assumption was false (obviously).

Debugging serial communications (and network communications for that matter) is a royal pain in the behind.  When something isn’t working, work the problem backwards.  When there’s hardware involved, verify that the hardware works or try to eliminate the hardware.  In my case, my Windows 7 doesn’t have a true serial port (it’s running on my Mac in VMWare).

So maybe you’ll learn something from my experience and pain.  Maybe you’ll keep yourself from having a bruised forehead (from banging your head up against a brick wall).

Happy coding!