Version 9 (modified by Valik, 15 years ago) (diff)

Rewrote some stuff and added some stuff.

Welcome to the AutoIt issue tracker

The AutoIt issue tracker is the new system for placing bug reports and feature requests for AutoIt. Please take a moment to read over this page and get an understanding of what you need to do in order to help the developers improve the AutoIt language.

General Notes

  • Please use the following syntax when inserting code. It helps the code stand out making it easier to read.
    MsgBox(0, "", "This is source code")
  • If you must post a large piece of code then please attach the file instead of posting it in-line.
  • When creating a ticket please do not set the Milestone value. The Milestone value is for developer use only. The developers set the Milestone when they close a ticket that involves some sort of modification to AutoIt. The Milestone the developers set is the future release of AutoIt where the bug is fixed or the feature is added. This may be a version that has not yet been released.
  • When creating a ticket please do not set the Blocking flag. The Blocking flag is for developer use only. The developers set the Blocking flag when they have open tickets they want to ensure are resolved before the next major release. What gets considered for blocking is entirely up to the developers and is not subject to discussion except amongst the developers. Don't set the Blocking flag.
  • Do not demand priority for your issue. People always suggest their issue should receive priority because it's important to them. It's a waste of time to suggest priority and will just lead to your ticket being ignored for longer than it would have otherwise been. It is up to the developers to choose what they want to work on and when it gets worked on.
  • Do not argue about the resolution a ticket is given unless you can prove that closing the ticket was a mistake.
  • Do not ask for support. This is for bug reports and feature requests only. See the ‚ÄčAutoit forum to ask for support.
  • Tickets should be stand-alone. They should contain all the information necessary to reproduce the issue without the need for links to the forum. It is acceptable to link to the forum so the developers may see the discussion that lead to the discovery of the bug. However, linking to the forum without extricating the pertinent information and using that to create the ticket will result in the ticket being ignored and closed.

How to report bugs

The developers need a few things from you when you report a bug in order for them to diagnose and fix a bug.

  • A short script that reproduces the issue. The developers don't care what you're trying to do that lead you to discover the bug. They only care about the bug itself so show only that.
  • If the reproduction script requires an external program in order to replicate the bug then try to find alternatives. Try to demonstrate the bug using an AutoIt GUI instead of an external application. Try to favor an application that comes standard with Windows. As a last resort try to find an easy to obtain and install application that demonstrates the issue. The more complex it is to reproduce a bug the less likely the developers are to spend their time working on it.
  • Show the output from the _DebugBugReportEnv() function. The following script can be used to put the information from that function onto the clipboard. You can then paste it into your bug report. This information will help the developers ensure that the problem isn't due to Windows itself.
    #include <Debug.au3>

How to ask for new features

  • A list of things '''not''' on the ToDo list - READ FIRST
  • Seriously, go and read this page again. Do not ask for these things.
  • When creating a feature request, please unset the version field. The version field is not used with feature requests. In addition the blocking and milestone fields should be left empty as well.
  • Think about your feature request. If you can do it via UDFs, then don't ask for it to be built in. There's a reason you can create your own functions.
  • Don't ask the developers to write UDFs. If you want to see UDFs added then you'll need to write it or get someone else to write it and submit it with the proper documentation.
  • Don't assume that just because you need a feature that the majority of people will use the feature. In other words don't ask for very niche things. This is doubly true if you can do what you need via a UDF. Things added to the language are intentionally very broad to reduce bloat.

Useful Reports

Here are some useful reports to take you to various types of tickets. Unless otherwise specified these reports are sorted by the last modification date.