Extensibility

AutoIt Extensibility

⮜ Extended Features | ⮨ Back to the Index | ➤ Tutorial: Creating a plugin

As previously mentioned, the AutoIt Interpreter strives to be as flexible, extensible, and modular as possible. Many aspects of the Interpreter can be changed, including — but not limited to — the parsing behaviour, symbol/macro/function resolution and its CLI language.

Built-in extensions

The Interpreter comes with a few built-in extensions shipped.

[TODO]

A more detailed guide to already built-in extensions and functionality can be found in the article about the Interpreter's extended features.

Custom extensions/plugins

The AutoIt Interpreter currently supports a wide range of extensions / plugins:

• Custom CLI language packs
  Custom language packs can change various text elements of the command line interface (CLI). This usually contains various error and warning messages — but not the direct output of the executed AutoIt-script.

• Directive processors
  Directives start with the pound sign (#) and usually contain meta-instructions not strictly semantically related to the script's execution. Examples for directives are #include "..." and #cs or #ce.

  Custom directive processors allow developers to introduce a processing logic their own directives, e.g. #my_dirctive.

• Pragma processors
  Pragma processors are a special sub-class of directive processors. Instead of handling an entire directive, they only process the values given to a #pragma [...]-directive. The AutoIt specification only supports compile as valid #pragma-option, however, maybe some developers would like to extend the #pragma-directive with their own options.

• Include resolvers
  Include resolvers are components which provide the Interpreter with a resolved script given an unresolvable file name. These resolvers get called when a command line invocation of the Interpreter or an #include "..."-directive points towards an invalid file.

  The AutoIt3 Interpreter ships with the following include resolvers as default:

  • UNC file resolution (for referencing an script via a network drive or any Samba-compatible device)
  • File resolution with missing file extensions: e.g. #include "~/docs/script3" will be resolved to ~/docs/scirpt3.au3
  • HTTP/HTTPS file resolution: #include "http://example.com/my_script.au3"
  • FTP/SFTP file resolution: #include "ftp://username:password@example.com/path/to/my/script.au3"
  • SSH/SCP file resolution: #include "ssh://username:password@example.com:22/path/to/my_script.au3"

  Check out the article about the Interpreter's extended features for more information on (non-local) file resolution.

• Statement processors
  Statement processors handle the processing of statement lines given that a specified regex expression is matched. The processors can hereby augment the AutoIt3 language with new keywords or constructs, e.g. Try ... Catch ... EndTry.

• Line processors
  Line processors are statement processors which handle a script line if no other processor could handle them. These are the most flexible processors and are required if developers want to extend the current expression syntax (e.g. to incorporate pointers or inline lambda expressions).

• Function providers
  Function providers act as native (non-user) function libraries and provide a list of functions callable from any AutoIt script. The AutoIt Interpreter comes shipped with the class FrameworkFunctions which provides (nearly) all functions specified in the official AutoIt3 Function Reference.

• Macro providers
  Macro providers work analogously to function providers. Instead of registering native functions, they can provide custom Macros to be used in any AutoIt script. The AutoIt Interpreter comes shipped with the class FrameworkMacros which provides (nearly) all macros specified in the official AutoIt3 Macro Reference.

A tutorial on how to create any extension or plugin as listed above can be found here — except for custom language packs: please refer to the following section for instructions on how to create them.

Custom CLI Language Packs

If you wish to add a new language pack to the interpreter, create a new YAML file and name it lang-xx.yml, where xx is the two-digit country/language code. The YAML file must contain the "meta"- and "strings"-sections as follows:

meta:
    code: "xx"
    name: "my_language"
    beta: true
    author: "my name"
strings:
    # ...

Save the YAML language pack file to the folder "lang/" (relative to the autoit3.dll-binary) in order for them to be used by the Interpreter. The language pack can then be used as follows:

$ autoit3 -l xx [...]			# short version
$ autoit3 --lang xx [...]		# long version

A list of all required strings for a complete YAML language pack can be found inside existing language packs, e.g. inside lang-en.yml.