Reporting bugs and making feature requests
If you think you have found a bug in Xojo or have a feature request, please report it in Xojo’s Feedback application. Feedback is designed to gather all the necessary information that helps us track down bugs and implement feature requests.
For each bug or feature request reported (called a case), you will receive a confirmation message via email with the case number. You will get emails when case info is added or when the status changes to Information Required, Fixed, Implemented or Closed.
You can launch the Feedback application directly from within Xojo. Just choose Help > Xojo Feedback or click the Feedback button on the toolbar. If you have already installed Feedback this will open the Feedback application. If you have not yet installed Feedback, your default web browser will open the Xojo download page where you can download Feedback for your OS.
If you have having trouble connecting to Feedback, be sure that you are using the latest version from the Xojo download page.
Using the Feedback app
The Feedback app has three main areas: the search field, the sidebar and the case area.
Searching and creating new cases
You have to search before you can create a new case.
The search field is where you search for cases. You have to search for cases before you can create a new case. This is to help people find an existing case on the same topic and prevent duplicates. If you want to create a new case, enter the title for the case as the search criteria to see a list of similar cases. After you search, you will have the ability to save your search (into the sidebar Folders section) or to create a new case. You can also just double-click any case in the search results to view the case.
When searching, “AND” is always implied between keywords
You can use the “-” character to exclude specific words from the search: toolbar -linux
The “|” is used to mean “OR”: Str | StrB
You can use parenthesis to group items: listbox -(hierarchical | checkbox)
Use quotes to search for phrases: “windows build”
The index skips common words and abbreviates common suffixes
When you are creating a new case, there are several fields that require information:
Summary: Include a descriptive summary. For feature requests, describe the problem you are trying to solve.
Product: Select the project for which this applies, usually you’ll just choose “Xojo”.
Case Type: This can be a Bug, Beta Bug or Feature Request.
OS: Choose the OS you are using when you noticed the issue.
Xojo Version: Choose the version of Xojo you are using.
Steps to Reproduce: Include details steps on how to reproduce the issue. Cases with reproducible steps are far more likely to be fixed. See below for formatting tips.
Expected Result: The result you expected to get.
Actual Result: The actual result you got.
Workarounds: Any workarounds for your issue that you have found.
Attachments: To include attachments, first create your case then use Add Information shown below.
Visible To: Choose who can see your Feedback case. The default is typically “Everyone”, but if you have private information in the case you can choose “Only me and Xojo”. For Beta cases, choose the appropriate Beta visibility.
You can add additional information to any case, even ones you did not create. To do so, click the “pencil” icon on the bottom toolbar to open a new Case Detail area where you can enter additional text, attachments and specify the visibility.
To add private information to a case (including a private project), create the case normally and then choose the “pencil” icon to add additional information to the case while setting the visibility to “Only me and Xojo”.
The case area can show information about a case or cases. You can also click on the Dashboard in the sidebar to show an overview of cases you have created or ranked.
When a list of cases is displayed, such as for search results, you can customize the visible columns by using View > Customize List Columns feature. You can click on any of the headers to sort the list. If you want an avatar to appear next to your name on your cases and comments, create a Gravatar account and associate it with the email used by your Xojo account.
When viewing a case, you can see its original title and description along with notes added to the case. You will also be able to see the overall status of the case.
In the case description, you can format code snippets by using the [code] tag:
[code] Var i As Integer i = 10 [/code]
As cases progress through the system, their status changes. Here is a list of statuses and what they mean.
Open: The case has been received by Xojo.
Scheduled: The case has been scheduled for development. (Feature Requests only)
Fixed: A fix for this case has been made and is pending verification.
Fixed and Verified: The fix for this case has been verified and is available in the Xojo version indicated on the case.
Implemented: The feature has been completed and is pending verification.
Implemented and Verified: The feature has been verified and is available in the Xojo version indicated on the case.
Closed: The case has been closed for the specified reason.
Information Required: The case is waiting for additional information from the author.
Archived: The case has had no activity in the last 2 years.
Ranking your cases
Use the My Top Cases selection in the Sidebar to rank cases. Drag open cases from the sidebar onto one of the rank areas to rank the case. You can rank your top 5 cases. The ranking works as follows:
Each active license you have for Xojo counts as 1 point
A Xojo Pro license counts for 12 points total (4 points for each license multiplied by 3)
Assigning a case to a higher ranking multiplies your points. If you have a single license, then a 5th place rank for a case gives it 1 point. A 1st place rank for a case gives it 5 points.
Under each ranking position, you will see how many points are applied to cases.
Creating good cases
It is easy to create Feedback cases, but it is not so easy to create good cases. These are the types of cases you can create: Beta Bug, Bug, and Feature Request.
Beta Bug: A bug that was found in a current Xojo beta.
Bug: A bug that was found in the currently shipping version of Xojo.
Feature Request: A change or suggestion for new functionality.
What makes a good case? A good case is a case that is well defined, with reproducible steps and usually an associated project that demonstrates the issue.
It starts with a good summary. Feedback uses intelligent phonetic searching on the summary of each case. It does not search the details of the cases. A good case summary should be a few words which best describe the nature of the case.
A good case summary describes the problem enough that action can be taken. A summary such as “HTMLViewer doesn’t work” is insufficient because it’s far too broad. Such a case is likely to require more information from you and slow the process of resolving it. Take your time and write a summary that provides enough detail about the problem you’re seeing. A good case summary does not propose a solution. For example, “HTMLViewer should use WebKit only” is not a good summary whereas “HTMLViewer should render pages the same on all platforms” is because it describes the problem you are trying to solve.
For bugs, the details should describe the issue more clearly and then include steps to reproduce the it. Ideally you will want to also attach a sample project that demonstrates the issue. Our statistics show that cases with sample projects are fixed faster than cases without sample projects. If a case is created that cannot be reproduced it’s status may be changed to “Closed” or “Information Required”. In both those situation, you will want to provide additional information if you want the case to remain open.
For feature requests, the details should describe the problem you need to solve. Try to limit specific implementation suggestions.
Reporting IDE performance issues
If you are finding that the IDE performs quite slowly under certain specific circumstances, we will need information from you showing the performance issue to be able to determine the problem. This information comes in the form of a file that provides us with a sample of how Xojo is performing on your computer.
Getting an OS sample on Mac
Follow these steps to get a macOS process sample. Get Xojo into a state where its performance is slow: 1. Open Activity Monitor app (In Application/Utilities).
Select the Xojo process.
Click the “gear” icon and select “Sample Process”. Or select View > Sample Process.
This displays the “Sample” window. It will refresh with sample text.
Click the Save button to save the text to included in your Feedback case. You can click the Refresh button to sample again if necessary.
Getting an OS sample on Windows
To gather system profiling information on Windows: 1. Download the latest release of UIforETW.
Unzip, launch etwpackage\bin\UIforETW.exe, and click “Start Tracing”.
Press Ctrl-Win-C after the event in question.
The tool is very low overhead and uses a circular buffer, so it can be kept running all of the time. Depending on system activity, there’ll be around 5-500 seconds of data available. The author of the tool has a more in-depth overview on recording ETW traces or, if you want a lot more information, a whole series of blog posts on ETW:
The resulting trace file can be attached to a Feedback case so that Xojo can analyze it to see what is causing the slowdowns.
If you are having trouble accessing Feedback, here are some things to check:
Download and install the latest version version.
Verify you have correctly entered your Xojo account information.
If you are using a Proxy, ensure the proxy information has been entered.