Delphi DevKit

Utilities for developing in Delphi using VS Code.

This project is not affiliated, associated, authorized, endorsed by, or in any way officially connected with Embarcadero Technologies, or any of its subsidiaries or its affiliates. The official Embarcadero Technologies website can be found at https://www.embarcadero.com/.

This extension does not include any proprietary Embarcadero code, libraries or binaries. To build Delphi projects, you must have a valid Delphi installation and the necessary environment variables set up. This extension does not work with the Delphi Community Edition due to its limitations on command-line compilation.

This extension is currently developed in my free time, and any feedback is welcome.

Features

• Dual Project Views: Two separate project management approaches:
  • Self-Defined Workspaces: User-customizable project workspaces with drag & drop support
  • Loaded Group Project: Load and manage Delphi group projects (.groupproj) - readonly view
• Multi-Compiler Support: Configure and switch between multiple Delphi versions (Delphi 2007 → Delphi 13.0 Florence built-in)
• Project Management: Compile, recreate, run, and manage Delphi projects with keyboard shortcuts
• Bulk Compilation: Compile or recreate all projects in a workspace or group project at once; cancellable at any time
• Workspace Management: Create, rename, remove workspaces and move projects between them
• File System Integration: Show projects in Explorer, open in File Explorer
• Configuration Management: Create and configure .ini files for executables
• Visual Indicators: File icons for Delphi files and missing file indicators
• Configuration Import/Export: Backup and restore your entire DDK configuration
• File-Based Persistence: Project and compiler data stored as RON files in %APPDATA%/ddk/
• File Navigation: .pas <-> .dfm swapping with Alt+F12 hotkey
• Smart Navigation: .dfm -> .pas jumps with Ctrl+click
• Compiler Output Enhancements: Timestamps, clickable file links, and diagnostics published to the Problems panel
• Formatter Support: Configurable Delphi code formatter.
• DelphiLSP Settings Generation: Generate the .delphilsp.json file Embarcadero's DelphiLSP extension needs for code insight, without ever opening RAD Studio
• LSP Server: Bundled ddk-server (Rust) handles all project state, compilation, and formatting
• MCP Server: Bundled ddk-mcp-server exposes project and compiler management as MCP tools for AI assistants (VS Code Copilot, Claude Desktop, etc.)
• CLI (ddk): Standalone command-line interface for managing projects and compilers outside of VS Code. Install via WinGet or use the bundled binary.

Installation

VS Code Extension

Install from the Visual Studio Marketplace. The extension bundles all Rust binaries — no extra setup needed.

CLI (standalone)

winget install ValentinBaron.DDK

Or download ddk-windows-x86_64.zip from the latest release and add ddk.exe to your PATH.

CLI Usage

ddk project list                       # List all known projects
ddk project select <ID>                # Select a project by ID
ddk projects add <PATH> <WORKSPACE>    # Add a .dproj/.dpr/.dpk to a workspace (by name)
ddk projects add_workspace <NAME> <COMPILER>  # Create a workspace bound to a compiler
ddk compiler list                      # List available compiler configurations
ddk compiler set <KEY>                 # Set the group project compiler
ddk compile                            # Compile the active project
ddk compile <ID|NAME>                  # Compile a project by ID or name (= -p; lists candidates if ambiguous)
ddk compile -p <ID|NAME>               # Same, explicit flag form
ddk compile --rebuild -p <ID>          # Rebuild a specific project by ID
ddk compile --debug-info <ID|NAME>     # Compile with the full debug artefact set (.map/.rsm/TD32, optimizations off)
ddk compile <PATH>                     # Compile a .dproj/.dpr/.dpk (uses the owning project if managed, else ad-hoc)
ddk compile <PATH> -c "Delphi 12"      # ...choosing the compiler (key or product name)
ddk compile <PATH> --config Release --platform Win64   # ...with build overrides
ddk compile --show-warnings            # Include warnings verbatim
ddk compile --show-hints               # Include hints verbatim
ddk compile --summarize-diagnostics    # Append `<file>: X warn, Y hint` per project
ddk compile -e windows-1252            # Decode compiler output with a specific encoding
ddk compile --fail-on-error            # Exit non-zero when the compile fails
ddk compile <ID|NAME> -- /p:Foo=Bar    # Pass extra arguments verbatim to MSBuild (after `--`)
ddk run                                # Run the active project's executable
ddk run <ID|NAME>                      # Run a project by ID or name (= -p; lists candidates if ambiguous)
ddk run <PATH>                         # Run a .exe directly, or a .dproj/.dpr/.dpk's owning project
ddk run -a "-flag \"value with spaces\""  # Override the project's saved Start Parameters for this run
ddk delphilsp-config                   # Write the active project's .delphilsp.json (DelphiLSP code insight)
ddk delphilsp-config <ID|NAME|PATH>    # ...for a specific project (lists candidates if ambiguous)
ddk delphilsp-config <PATH> -c "Delphi 12"   # ...choosing the compiler for an unmanaged path
ddk delphilsp-config <PATH> -o <FILE>  # ...writing somewhere else instead of next to the project
ddk debug-target                       # Describe the active project's debug target (exe/host, symbols, sources, args)
ddk debug-target <ID|NAME|PATH> --json # ...for a specific project, as JSON for a debugger integration
ddk debug-target <ID|NAME> --config Release --platform Win64  # ...as that configuration/platform would build it
ddk env                                # Show active project & compiler info
ddk info                               # Print the DDK README
ddk --json <command>                   # Output as JSON

ddk compile <PATH> compiles a .dproj/.dpr/.dpk. If the file already belongs to a managed project it is compiled as that project (and a file shared by several projects lists the candidates instead of compiling); otherwise it is compiled ad-hoc without adding it to the saved project list (handy for one-off builds). For the ad-hoc case --compiler/-c selects the compiler by exact key (12.0) or product name (Delphi 12), defaulting to the newest installed compiler. The same is exposed to AI tooling via the MCP delphi_compile_file, delphi_add_project, and delphi_add_workspace tools.

Anything after a -- separator on ddk compile is passed verbatim to MSBuild (e.g. ddk compile be -- /p:DCC_Define=FOO /m). These extra arguments are appended after DDK's own /p:Config//p:Platform args, so a /p: override here wins (MSBuild takes the last value). They have no effect on a bare .dpr/.dpk target, which is compiled with the command-line compiler (dcc) rather than MSBuild — DDK prints a note when they are ignored.

ddk compile --debug-info (MCP: debug_info: true; VS Code: the Compile for Debugging actions) forces the full debug artefact set a debugger needs — optimizations off, TD32 debug info in the binary, the .rsm remote-debug symbols and a detailed .map — regardless of what the selected build configuration says, so a Release build can be debugged without editing the project; the dproj is never modified. For a .dproj the flag passes exactly these MSBuild global properties: DCC_Optimize=false, DCC_DebugInformation=2, DCC_LocalDebugSymbols=true, DCC_SymbolReferenceInfo=2, DCC_GenerateStackFrames=true, DCC_DebugInfoInExe=true, DCC_RemoteDebug=true, DCC_MapFile=3. They go before anything passed after --, so a /p:DCC_* override of yours still wins. A bare .dpr/.dpk gets the dcc switches -$O- -$D+ -$L+ -$Y+ -V -VN -VR -GD, plus -B so every unit is rebuilt with them (the MSBuild path cleans first for the same reason: an up-to-date DCU from a Release build would otherwise be reused as is).

ddk compile --json (and the MCP compile tools) return a fully machine-coded result: structured header fields (project, project_path, compiler, config, platform, action, success, code) plus a diagnostics object grouped into errors/warnings/hints, each entry carrying {code, file, line, message}. There is no raw log text. Diagnostics obey the same --show-warnings / --show-hints filters — errors always appear, warnings only with --show-warnings, hints only with --show-hints — so a slim compile stays slim; pass both flags to get every diagnostic. Compiler output is decoded using the active console output codepage (what chcp sets); use -e/--encoding (or the DDK_COMPILER_ENCODING environment variable) to force a specific encoding. By default ddk compile exits 0 even on a failed compile (the result is in the JSON); pass --fail-on-error to exit with the compiler's exit code instead (a cancelled compile exits 2).

Compile output for the CLI and the MCP delphi_compile_project tool is trimmed for AI / token-efficient consumption: the decorative banner box is stripped and warning / hint lines are hidden by default. Errors and the final status line are always shown.

ddk run <PATH> dispatches on the file extension: a .exe is launched directly; a .dproj/.dpr/.dpk must already belong to a managed project (its stored executable is run, same resolution as by name) — it is never compiled or run ad-hoc. A project with a configured Host Application (the Debugger_HostApplication from Project > Options > Debugger in the Delphi IDE, or the DevKit Set Host Application override, which wins) runs that host executable instead — matching the IDE, and making a .dpk package project runnable at all. --args/-a overrides the run parameters for that one run; the process is launched detached, so the CLI/MCP call returns immediately without waiting for it to exit. The same is exposed to AI tooling via the MCP delphi_run_project and delphi_run_file tools.

ddk delphilsp-config writes the <project>.delphilsp.json settings file that Embarcadero's DelphiLSP VS Code extension reads for code insight (completion, go-to-definition). That file is normally produced only when the project is opened in the RAD Studio IDE, so code insight is dead for anyone working purely in VS Code. DDK reconstructs it from the project's .dproj (evaluated for the effective configuration/platform), the compiler installation's bin\rsvars.bat, and the IDE's global Library Path, Browsing Path and user-defined environment variables read from HKCU\SOFTWARE\Embarcadero\BDS\<version>. Search-path entries whose $(MACRO) cannot be resolved are dropped and reported as warnings. The target resolves like ddk compile: an ID, a name, or a path (ad-hoc when the path belongs to no workspace). Re-run it after changing the project's search paths, defines, configuration or platform. The same is exposed to AI tooling via the MCP delphi_generate_delphilsp_config tool, and to the VS Code extension via the delphilsp/generate LSP request.

Every file DDK writes carries a top-level "generatedBy": "delphi-devkit" key next to "settings". RAD Studio never writes that key, so it marks the file as DDK's to maintain: the VS Code extension refreshes a stale configuration only when the marker is present, and leaves an IDE-generated or hand-written .delphilsp.json alone. Running ddk delphilsp-config explicitly always rewrites the file regardless of the marker.

In the VS Code extension the integration activates only when the DelphiLSP extension (EmbarcaderoTechnologies.delphilsp) is installed — no commands or menu items appear otherwise, and installing it later enables them on the fly. A Generate DelphiLSP Config context-menu action is added to projects in the DDK tree, and whenever the active project changes DDK keeps DelphiLSP in sync automatically (ddk.delphilsp.autoSync, on by default): it points DelphiLSP's delphiLsp.settingsFile at the active project's .delphilsp.json, generating the file on the fly when it is missing — or regenerating it when it is DDK-owned and its .dproj content has changed since generation — so code insight always resolves units, defines and search paths in the context of the project you are actually working on. Because the generated files are machine-specific, DDK also keeps them out of version control by adding *.delphilsp.json to the owning repository's local .git/info/exclude (ddk.delphilsp.autoIgnoreDelphiLspFiles, on by default; disabling it removes exactly the entry DDK added, nothing else). Because DelphiLSP's server applies a settings change only to files opened afterwards (its own Select project settings command leaves already-open files with stale diagnostics until they are edited), DDK also re-validates every open Delphi file after the switch via an invisible language-mode round-trip that re-emits didOpen — tabs, focus, cursor, dirty state and undo history are untouched (ddk.delphilsp.revalidateOpenFilesOnSwitch, on by default).

With both extensions active the Problems view would otherwise show the same error twice — once from DDK's last compile and once from DelphiLSP's live analysis — and DDK's copy would go stale the moment the code is fixed, since it only refreshes on the next compile. DDK therefore merges the two: whenever DelphiLSP reports live diagnostics for a file, every DDK compile diagnostic matching one of them (same line, same Exxxx code) is removed, leaving only the live entry with its precise token range — and when DelphiLSP later clears that entry because the error was fixed in the editor (even without recompiling), no stale compile copy resurfaces. Compile diagnostics DelphiLSP knows nothing about (files it has not validated, link errors) keep their normal lifetime, and without DelphiLSP installed nothing is ever removed (ddk.delphilsp.mergeDiagnostics, on by default).

Without --args, a project runs with the .dproj's own Debugger_RunParams — the Run Parameters set via Project > Options > Run in the Delphi IDE, resolved against the project's active configuration/platform — fused with the saved Start Parameters (see Set Start Parameters below): the dproj value comes first, the saved value is appended after, so both take effect rather than one silently replacing the other. In the VS Code extension this can be turned off with the ddk.projects.useDebuggerRunParams setting: disable it to always use only the saved Start Parameters, ignoring the dproj's Run Parameters entirely. The CLI/MCP always fuse Debugger_RunParams in, since there is no extension setting for them to consult.

In VS Code, a project started with Run / Run Selected Project (F9) runs inside the editor instead of in a console window that closes on exit. ddk.projects.runIn picks where:

• terminal (default) runs the executable in its own DDK Run: <project> terminal — as a task — with the project's run parameters and the executable's directory as the working directory. A terminal is a real console (ConPTY), so everything a console gives a program keeps working: its own colors, output that the view follows, and keyboard input for a program that reads stdin. When the program exits, the terminal stays open on its finished output until you close it or the next run of that project reuses and clears it (each project gets its own terminal). Being a task, the run also shows up under Terminal > Run Task history and can be repeated with Rerun Last Task.
• output pipes stdout and stderr into the DDK Run output channel instead, framed by a header with the exact command line and a footer with the exit code and elapsed time — searchable text that survives the run. The channel is cleared when a run starts (unless another run is still writing to it) and, for a GUI application that prints nothing, is only revealed once output actually appears (ddk.projects.runRevealOutput).
• detached is the old behavior: launched detached, output discarded.

ddk run on the CLI is unaffected — it always launches detached.

What a pipe cannot carry, and why terminal is the default: a program coloring its output through the Windows console API (SetConsoleTextAttribute — what DUnitX's test runner uses) writes no color information into stdout at all. The color is an attribute of the console screen buffer's cells, set by a side-channel API call; with the handle redirected to a pipe that call simply fails, so nothing about it reaches DDK, and no reader could recover it. Only a real console produces those colors — which is exactly what ConPTY gives the process, and it re-encodes them into escape sequences the terminal renders. In output mode the text is therefore plain: the Output panel renders no ANSI escape sequences either, so any that a program does emit are stripped, along with carriage-return overwrites (a self-rewriting progress line keeps only its final state) and other control characters, rather than showing up as ←[32m litter. Keyboard input is impossible there as well (a program reading stdin sees end-of-file), the process is a child of VS Code — closing VS Code breaks its output pipe — and VS Code's own "smart scroll" stops the panel from following new output once the cursor sits off the last line (output.smartScroll.enabled: false, or View: Toggle Locked Scrolling, releases it).

Output in output mode is decoded with Windows' own default charset for non-Unicode text — the system ANSI codepage (GetACP, e.g. 1252) — which is what a program writing to a redirected handle normally produces; ddk.projects.runOutputEncoding switches it to oem (the console codepage such as CP850), utf8 (what a current Delphi RTL writes while redirected), a fixed codepage, or auto, which takes each line as UTF-8 when it is valid UTF-8 and as the ANSI codepage otherwise. A terminal decodes its own output, so the setting does not apply there.

Because the output channel cannot forward keystrokes, a captured program's stdin is not connected: one that reads input sees end-of-file instead of hanging invisibly. Run such a program from a terminal, or disable ddk.projects.runInOutputChannel.

ddk debug-target describes what debugging a project means, independently of any particular debugger: the executable to launch or attach to (the program itself, or the Host Application that loads a package or a DLL), the .map/.rsm symbol files next to it, the project's own .bpl/.dll module with its symbols and .dcp, the source search paths (the project directory, the dproj's unit and include paths, the IDE's Library Path and Browsing Path for the platform, the compiler's source tree — macros expanded through rsvars.bat and the IDE's environment-variable overrides), the run arguments exactly as Run passes them, and config/platform/bitness. Nothing is written or compiled.

Two rules make the answer safe to act on:

• A path in it is a file that was found. symbols.map/symbols.rsm, and a module's binary, map, rsm and dcp, are null when the file is not on disk — or is there but cannot belong to the binary: empty, or written by another build (more than five minutes apart from it, either way). The one exception is executable, which names the program even before its first build. Search path entries that do not exist are left out.
• warnings are problems, notes are information. A warning means the session will be degraded or will not work: a missing executable or module, missing, empty or stale symbols, a platform the project does not enable or Windows cannot debug, a value depending on a $(NAME) nothing defines, an unreadable dproj or rsvars.bat, a different copy of the package sitting in the host's directory. A note explains what DDK decided or left out without harm: the compiler an unlinked project is described with, an IDE path that is not configured, search path entries that do not exist. An empty warnings list means ready to debug.

A package or a DLL is named after the project's main source plus its LIBSUFFIX — the dproj's DllSuffix ($(Auto) being the compiler's package version), else the {$LIBSUFFIX} the .dpk declares for this compiler and platform, conditional directives evaluated — and looked up by that exact name in, in order: the dproj's DCC_BplOutput, the IDE's Package DPL Output, $(BDSCOMMONDIR)\Bpl\<Platform> (and $(BDSCOMMONDIR)\Bpl for Win32, where Win32 packages land), the project's .\<Platform>\<Config>, and the host's directory. The .dcp follows the same order through DCC_DcpOutput, Package DCP Output and $(BDSCOMMONDIR)\Dcp, ending next to the .bpl.

The target resolves like ddk compile: an ID, a name, or a path (ad-hoc when the path belongs to no workspace). -c picks the compiler of a project that has none of its own — an ad-hoc path, or a managed project linked to no workspace; a linked project builds with its workspace's compiler, and the target notes that the option was ignored. --config/--platform describe that configuration and platform instead of the project's active ones: the executable, the Host Application and the run parameters are discovered anew for that build, so what is described is what such a build produces, never the active build's files under another name. --json is the form a debugger integration consumes: a debug adapter's extension maps it onto its own launch attributes, so a hand-written launch configuration shrinks to a project reference and stays correct when the project's paths change. The same is exposed to AI tooling via the MCP delphi_get_debug_target tool and to the VS Code extension via the debug/target LSP request.

In the VS Code extension, debugging goes through whichever installed extension contributes the delphi debug type; DDK itself ships no debugger. While one is installed, every project gets Debug and Attach Debugger actions (context menu, command palette, Ctrl+Alt+F9 for the selected project) and one dynamic entry per project in the debug dropdown. All of them start the two-line configuration { "type": "delphi", "request": "launch" | "attach", "ddkProject": "<name or id>" } — the same shape a hand-written launch.json entry can use — and the debugger extension resolves it by asking DDK for the project's debug target through the ddk.debug.getDebugTarget command (executeCommand with { project?, compiler?, config?, platform? }, all optional).

By default a session starts on the binaries as they are: compile when you know it is needed, with Compile for Debugging on the project or the selected project. Ctrl+F9 is the plain compile and leaves out the debug artefacts a debugger needs. F5 with no launch.json debugs DDK's active project. With ddk.debug.compileBeforeDebug on, every launch first compiles the project for debugging, however the session was started: the context menu, the debug dropdown, a launch.json entry naming a ddkProject, or F5. The session then starts only when that build succeeded; a build you cancel cancels the session without an error. The setting is off by default because a DDK compile always cleans first, so it would rebuild the whole project for every session. An attach never compiles, and when several instances of the executable are running the debugger's own process picker chooses. Every project is offered, built or not. DDK never writes a launch.json.

Demos

Add a Workspace and drag in a Project

Add a Project via dialog

Load a Group Project

Compile a Project

Transfer Group Project to Workspace

Format Delphi Source

Commands

File Navigation

• Swap .DFM/.PAS - Switch between form and unit files (Alt+F12)

Project Management

• Select Delphi Compiler for Group Projects - Choose the active compiler configuration for .groupproj files
• Pick Group Project - Load a Delphi group project (.groupproj)
• Unload Group Project - Unload the currently loaded group project
• Transfer Group Project to Workspace - Convert the loaded group project into a self-defined workspace
• Refresh - Refresh the projects view and discover file paths

Workspace Management

• Add Workspace - Create a new self-defined workspace
• Rename Workspace - Rename an existing workspace
• Remove Workspace - Delete a workspace and its projects
• Add Project - Add projects to a workspace
• Remove Project - Remove projects from a workspace

Configuration

• Import Configuration - Import DDK configuration from JSON file
• Export Configuration - Export DDK configuration to JSON file
• Edit Default .ini - Edit the default INI template file
• Edit Formatter Config - Edit the Delphi formatter configuration file
• Reset Formatter Config - Reset the formatter configuration to defaults
• Edit Compiler Configurations - Open the compiler configurations RON file directly
• Edit Projects Data - Open the projects data RON file directly

Project Actions (Available via context menu and keyboard shortcuts)

• Compile Selected Project - Compile the selected project (Ctrl+F9)
• Recreate Selected Project - Clean and rebuild the selected project (Shift+F9)
• Compile Selected Project for Debugging - Compile the selected project with the full debug artefact set (.map/.rsm/TD32, optimizations off) regardless of its build configuration; also available per project (Compile for Debugging), per workspace and per group project
• Compile All in Workspace - Compile all projects in a workspace
• Recreate All in Workspace - Clean and rebuild all projects in a workspace
• Compile All in Group Project - Compile all projects in the loaded group project
• Recreate All in Group Project - Clean and rebuild all projects in the loaded group project
• Cancel Compilation - Cancel the active compilation (Ctrl+F2)
• Run Selected Project - Execute the selected project (F9)
• Debug Selected Project - Start a debug session for the selected project (Ctrl+Alt+F9), compiling it for debugging first only when ddk.debug.compileBeforeDebug is on; also Debug on any project. Shown only when an extension contributing the delphi debug type is installed
• Attach Debugger to Selected Project - Attach the debugger to the running instance of the selected project's executable (or Host Application); also Attach Debugger on any project
• Set Start Parameters - Configure command-line arguments passed to the executable when run
• Set Host Application - Configure the executable that hosts the project when run (e.g. the application loading a .dpk package); overrides the dproj's own Debugger_HostApplication
• Configure/Create .ini - Create or edit INI configuration files
• Set Manual Path - Manually set the .dproj path for a project

Extension Settings

• ddk.compiler.encoding: Character encoding used to decode MSBuild output (oem by default, use utf8 if your paths contain non-ASCII characters).
• ddk.debug.compileBeforeDebug: Before a Debug session starts, compile the project with the full debug artefact set (.map/.rsm/TD32, optimizations off), however the session was started — context menu, debug dropdown, launch.json, F5 — and start the session only if that build succeeded. false by default: a DDK compile cleans first, so this rebuilds the whole project for every session. Attaching never compiles.
• ddk.projects.useDebuggerRunParams: When running a project, fuse the .dproj's own Debugger_RunParams with the saved Start Parameters, dproj first (true by default). Disable to always use only the saved Start Parameters.
• ddk.projects.runIn: Where a run sends its output: terminal (default, a real console — the program's own colors, following output and keyboard input all work), output (piped into the DDK Run output channel: searchable text, no colors, no input) or detached (output discarded, as before).
• ddk.projects.runOutputEncoding: Encoding used to decode a running project's output in output mode (ansi by default: Windows' system ANSI codepage, e.g. 1252). Further choices: auto (per line UTF-8, falling back to ANSI), utf8, oem (console codepage), cp437/cp850/cp852, ibm866, windows-1250/windows-1252 and the ISO 8859 variants.
• ddk.projects.runRevealOutput: When to reveal the DDK Run channel in output mode: onOutput (default, as soon as the program prints something), always or never.

Compiler Configurations

Compiler configurations are stored in %APPDATA%\ddk\compilers.ron and managed by the DDK server. The extension ships with built-in presets for all Delphi versions from Delphi 2007 to Delphi 13.0 Florence.

You can view and edit them directly via the Edit Compiler Configurations command. Each entry includes:

• product_name / compiler_version / package_version — version identifiers
• installation_path — root path of your Delphi installation
• build_arguments — MSBuild arguments passed during compilation
• condition — optional expression to enable/disable the entry

The first entry whose Formatter.exe is found in its installation path is used for formatting.

Project Views

Self-Defined Workspaces

• Customizable: Create and organize your own project workspaces
• Drag & Drop: Move projects within and between workspaces
• Compiler Assignment: Each workspace has a predefined compiler
• Persistent: Projects and workspaces are stored in %APPDATA%\ddk\projects.ron

Loaded Group Project

• Read-Only: View projects from .groupproj files
• Compiler Selection: Use the compiler picker for group project compilation
• Cross-Copy: Drag projects from group projects to self-defined workspaces

Visual Indicators

• Selected Project: Shows ←S indicator for the currently selected project
• Missing Files: Shows ! indicator for files that don't exist
• File Type Icons: Custom icons for .pas, .dfm, .dpr, .dpk, .dproj files

Keyboard Shortcuts

• Alt+F12 - Swap between .PAS and .DFM files
• Ctrl+F9 - Compile selected project (when project is selected)
• Shift+F9 - Recreate selected project (when project is selected)
• F9 - Run selected project (when project has executable)
• Ctrl+F2 - Cancel active compilation

Known Issues

None so far.