Debugging Overview
From Xojo Documentation
Contents
What is debugging? Debugging means removing errors, both logical and syntactical, from your programming code. Errors in programming code are referred to as bugs, which has an interesting story behind it. Back in the 1940’s, the United States Navy had a computer that occupied an entire warehouse. At that time, computers used vacuum tubes and the light from the tubes attracted moths. These moths would get inside the computer and short out the tubes causing a failure. Technicians would have to go in and remove these "bugs" to make the computer work again. Since this was a government project, everything had to be logged, so they would put down “debugging computer” in the log and the term has stuck.
Debugging is a normal part of programming. In fact, whenever you click the Run button to run your project you are technically debugging. Even though debugging is often the part of programming that most programmers like the least, the Debugger makes it easy to track down your nasty bugs and squash them like a, well, bug.
Types of Bugs
There are two types of bugs you can make in your code: logical and syntactical.
Logical Bugs
These are bugs in your programming logic. You will know you have found one of these when your code compiles but does not produce the results you were expecting. These are also often indicated by an exception in your app. The debugger can help you find these types of bugs by letting you watch your code execute one line at a time so you can pinpoint where the problem is.
Logical bugs are by far the most common source of bugs.
Syntactical Bugs
These are bugs where you have mistyped the name of a keyword, class, property, variable, method, etc. These are often called Syntax Errors. You may have also tried to use two values together that don’t go together. For example, if you try to assign a String value to a variable or property of type Integer, you will get a Type Mismatch error because they are different data types.
These type of bugs are caught by the compiler, so you will never be able to even run your project if you have these types of errors.
Message Logging
One common technique that was commonly used before tools had integrated debuggers was to print messages to the screen. This can sometimes be useful even with Xojo. You can use the MsgBox method to quickly display a message to help with your debugging. But you should use this technique sparingly. Displaying messages like this can alter the processing of UI events and may make your app behave differently than it would without the message.
An alternative (and better) technique is to write messages to the Message Log, which is a panel that is displayed at the bottom of the Xojo Workspace. You use the System.DebugLog method to write messages that display in the Message Log:
These messages can also be viewed by OS logging tools, such as the Console app on macOS or the Microsoft DebugView tool on Windows.
Although the Debugger is a far better way to monitor the progress of your running app, using the Message Log can be useful for deployed apps.
Analyzing the Project
Since a project cannot be compiled if it contains syntax errors, you have the option of analyzing the project as a preliminary step. Choose Project ↠ Analyze Project or Project ↠ Analyze Item, where Item is the currently displayed project item. Analyze Project checks for issues but does not build the project. Some issues that it identifies are syntax errors, unused local variables and parameters, and type conversion issues.
 |
Analyze Project only checks code for the platform you are currently using. For example, Analyze Project will not see code within Pragmas for TargetWindows if you are running Xojo on Mac. |
Errors are indicated by a stop sign icon and will prevent you from being able to run or build your project. Warnings are indicated by a yellow warning triangle and do not prevent you from building or running your project.
If errors or warnings are found they are listed in the Errors panel at the bottom of the Workspace. Expand each row that is displayed to see the individual issues.
You can click on each issue to display the appropriate editor (usually the Code Editor) with the issue highlighted. You should fix any errors that are reported. And you should evaluate the warnings to see if you think they need to be fixed. Not all warnings need to be fixed.
The Type and Location buttons in the Issues pane allow you to change how to view the Issues. The Type button groups the issues by the type of the issue. So all the “Unused local variables” issues would appear together.
The Location button groups the issues by the object in which they occur. So all the issues for Window1 would appear together, for example.
Analyze Item
The Analyze Item command, available from the Project menu or on the Code Editor toolbar, works the same as Analyze Project but instead of analyzing the entire project, it only analyzes the code displayed in the Code Editor.
In the case of a Menu in a desktop project, Analyze Item checks for duplicate shortcuts.
Filtering Types of Warnings
You can control the types of warnings that the Errors panel displays. Choose Analysis Warnings from the Project menu to display a window that lists all the types of warnings that can be found. Only the selected warnings are reported when you analyze. Unselect any warnings that you do not wish to know about.
Warnings
These are the available warnings:
- Item1 is deprecated
- Item1 is deprecated. You should use Item2 instead
- Old-style constructor methods are no longer supported. You should use "Constructor" instead
- Unknown pragma name
- Converting from Item1 to Item2 causes a possible loss of precision, which can lead to unexpected results
- Converting from Item1 to Item2 causes the sign information to be lost, which can lead to unexpected results
- Performing a Item1 comparison on floating-point values can yield unexpected results due to their inexact binary representation.
- Custom warning string
- Item1 is an unused local variable
- Item1 is an unused method parameter
- Item1 is an unused event parameter
- This property shadows one already defined by Item1
- This constant shadows one already defined by Item1
- Before 2014r3, this would have referred to the Item1, but now it refers to the Item2.
- Using method Item1 from the 'Item2' library on this target is suspicious.
See Also
UserGuide:Debugger Usage topic