Changes from AutoHotkey to Keysharp

This page summarizes the structural differences between Keysharp and its AutoHotkey compatibility target, then indexes the pages which state each exact contract.

Table of Contents

• Core Differences:
  • Scripts are compiled, not interpreted
  • Three platforms, one language
  • A managed object model
  • Language additions
• Detailed Index:
  • Runtime and Language
  • Memory and Interop
  • GUI and Desktop Integration
  • Unavailable or Reduced Inherited Behavior

Core Differences

Scripts are compiled, not interpreted

AutoHotkey interprets a script. Keysharp reads it, lowers it to C#, and has Roslyn compile it to a .NET assembly which is then executed. How a Script Executes describes the pipeline, and the --transpile and --compile options expose its intermediate results.

As a result:

• An error's stack reports managed call frames, which name the C# methods the script was compiled into. A few built-in classes carry an internal type name in that output.
• ListLines has no compiled equivalent, and Thread is not line-aware.

Three platforms, one language

Much of the inherited library is defined in terms of Win32, and each platform meets that behavior to a different degree. Platform Support covers X11, Wayland, macOS permissions and foreign-window automation. On Linux and macOS, input and window control depend on OS-level permissions and helpers, and a script can declare what it needs with #Requires or RequestCapabilities.

On Linux and macOS, window styles, control messages and other Win32-level GUI facilities are unavailable or approximated; GUI Control Types and GUI Events record where.

A managed object model

Objects are .NET objects. Object lifetime and finalization follow the garbage collector instead of reference counting, so __Delete runs when the collector reclaims the object rather than when the last reference goes away. The reference-counting functions manage native COM references on Windows, including those of a script object's COM wrapper.

The same applies wherever a script reaches outside itself for memory: DllCall, CallbackCreate, StrPtr and ObjPtr operate on managed values, and StringBuffer is the writable string-memory type to pass to native code. For calling .NET directly, Clr is available.

Language additions

Keysharp adds:

• Conditional compilation and build directives, which act at compile time.
• The KS module, which holds the Keysharp-specific API surface, imported explicitly.

Detailed Index

Each link below leads to the canonical contract for that behavior.

Runtime and Language

• Increment/decrement, concatenation, concatenation assignment, numeric literals, unset values and dynamic dereferencing have documented implementation differences.
• Reference parameters accept additional target forms.
• Case-insensitive comparisons retain Unicode folding, and A_EventInfo provides an object for input hook events.

Memory and Interop

• #Package makes a NuGet package's assemblies available to Clr.

GUI and Desktop Integration

• Gui includes container-relative positioning, GroupBox containers, automatic scrolling, macOS application menus and visibility access.
• GuiControl, ListView, TreeView and Menu have additional methods and properties.
• WinEvent, Overlay and Image add cross-platform desktop facilities.

Unavailable or Reduced Inherited Behavior

The affected reference pages document the exact boundary. Notable areas include:

• interactive debugging and DBGp are not implemented;
• FormatTime flags and PixelGetColor mode;
• DirSelect and MsgBox modality; and
• OnMessage dispatch and Download options.

Version Differences

The differences above are between Keysharp and its AutoHotkey compatibility target. For changes between AutoHotkey versions themselves, see Changes from v2.0 to v2.1 and Changes from v1.1 to v2.0. For changes between Keysharp releases, see Recent Changes.