Re: Debugging / dealing with users
Posted: Mon Apr 23, 2012 8:45 pm
I use a two (or unusually three) pronged approach:
1. Use the OnError - I find that most of the time, just casting a fresh eye over a bit of code that you haven't touched in months will show the problem at hand.
2. Logging of all UI activity with the time - windows opened, windows closed, menu choices, buttons clicked, etc - to the last 1000. Sometimes it's the order of things done that changes variables unexpectedly - one problem that I struggled with for about a year was due to someone changing the program path to "C:\", simply because I'd used the wrong variable, but for most people who left it as the default path it was never a problem. Discovering the process that people do weeds out bugs that you may never consider in your test environment.
3. Create your own "Call Stack" - there are many examples of Stacks implemented in PB - for each Procedure entry and exit, you push and pop your current position in your code - complete with parameter values. I don't usually bother with this one unless something is really ticking me off, but I have done it when I just can't explain what reports I'm getting, and I can't strip out the code and/or make it any simpler. This is of course after using the built in debugger to do the same and I can't repeat it.
A couple of general tips which can help:
- Keep things modular - Try to keep all Procedures self contained - if that isn't possible, and variables have to be shared between several procedures, look up several of the OOP methods that are described here. The aim is that if you are getting errors, you can simple yank out the code and place it in a test app where you can manipulate the variables to your hearts delight.
- Keep Procedure sizes down - break them up if they are large. Smaller chunks of code is a lot easier to debug than a 5 page monstrosity - this also will help with OnError as the thrown error is narrowed down to a small section of code.
- Reduce Globals to a minimum. Yes, I know that they just so damned useful. If you want to keep code modular (easily testable), remove the Globals.
1. Use the OnError - I find that most of the time, just casting a fresh eye over a bit of code that you haven't touched in months will show the problem at hand.
2. Logging of all UI activity with the time - windows opened, windows closed, menu choices, buttons clicked, etc - to the last 1000. Sometimes it's the order of things done that changes variables unexpectedly - one problem that I struggled with for about a year was due to someone changing the program path to "C:\", simply because I'd used the wrong variable, but for most people who left it as the default path it was never a problem. Discovering the process that people do weeds out bugs that you may never consider in your test environment.
3. Create your own "Call Stack" - there are many examples of Stacks implemented in PB - for each Procedure entry and exit, you push and pop your current position in your code - complete with parameter values. I don't usually bother with this one unless something is really ticking me off, but I have done it when I just can't explain what reports I'm getting, and I can't strip out the code and/or make it any simpler. This is of course after using the built in debugger to do the same and I can't repeat it.
A couple of general tips which can help:
- Keep things modular - Try to keep all Procedures self contained - if that isn't possible, and variables have to be shared between several procedures, look up several of the OOP methods that are described here. The aim is that if you are getting errors, you can simple yank out the code and place it in a test app where you can manipulate the variables to your hearts delight.
- Keep Procedure sizes down - break them up if they are large. Smaller chunks of code is a lot easier to debug than a 5 page monstrosity - this also will help with OnError as the thrown error is narrowed down to a small section of code.
- Reduce Globals to a minimum. Yes, I know that they just so damned useful. If you want to keep code modular (easily testable), remove the Globals.