FAQ

FAQ

Is this a drop-in replacement for swiftDialog?

No. It covers the progress-reporting core — live progress bar, live list, live title/message/button text, a lockable window, a scriptable exit — and leaves out swiftDialog's form controls, JSON input and output, info-box chrome, notification mode and web view. Coming From swiftDialog maps it flag by flag.

Why did my dialog print to the console instead of opening a window?

Because you did not pass a front-end flag. dialog.exe only draws a window when it sees --window, --fullscreen, --kiosk, --firstrun, --autolaunch or --commandfile. Anything else falls through to a console prompt that blocks on stdin. Add --window. This is the number one issue for people arriving from swiftDialog, where a window is always the default.

Why does the dialog run as SYSTEM but nobody sees it?

Session 0 isolation. A process started by a Windows service, or by a scheduled task set to run as SYSTEM, draws on the session 0 desktop, which no interactive user can see. csharpDialog contains no session-shifting code — no CreateProcessAsUser, no WTS session enumeration — so it cannot move itself into the user's session. Launch it from the user's session instead: a logon scheduled task with an interactive principal, a Run key, or a logon script. The recipe is in Recipes.

Can I get exit code 2 for a second button, like swiftDialog?

No. The window has one button control, and the exit code is 0 when the button was pressed and 1 for a timeout, the quit key, or an error. If you need to tell those apart, parse the Result: line from stdout — it carries ok, button1, timeout or quit.

Does --message support markdown?

No. --markdown is parsed into the configuration and read by nothing; the message renders as plain text in a TextBlock. Shell-level newlines work; formatting does not.

Why does --icon (or --backgroundcolor, or --topmost) do nothing?

dialog.exe shows a fixed-layout window, and its service only assigns the handful of properties it explicitly reaches for. Icon, image, video, colours, fonts, topmost and the initial progress value are parsed into the configuration and never read. They are honoured only by the separate csharpDialog.WPF.exe host, which has no list, no progress bar and no command-file support — so it is not useful for the job. The full inert list is in the CLI Reference.

How do I show a per-application icon in a list row?

Pass an existing absolute file path as the third comma-separated field of --listitem:

dialog --window --listitem "Chrome,success,C:\ProgramData\ManagedInstalls\icons\chrome.png"

Bare names and URLs are accepted by the parser but the list control only loads an existing absolute path — the resolution logic that would handle names and downloads lives in a service the window does not call. Resolve the path in your script.

Why is my progress bar not moving?

Two likely reasons. The launch-time --progress <n> value is not applied by dialog.exe, so the bar starts wherever its XAML left it; and --progress-max is inert, so the maximum is fixed at 100. Use --progress with no value to make the bar visible, then send progress: 0 as your first command-file line and treat every value as a percentage.

Why is my listitem: update doing nothing?

Rows are keyed by exact title. Any difference in case, spacing or punctuation between the add and the update finds no row and silently does nothing. Store the title in a variable and reuse it. Titles containing commas cannot work at all, because the comma is the parameter separator.

How do I remove a row from the list?

You cannot. listitem: delete parses and does nothing, and list: clear has no handler. Add every row up front and change its status instead — which is also better for the user, who can then see the whole scope from the start.

Is there a JSON configuration file, like --jsonfile?

Not usable. A complete JSON schema, parser and validator exist in the source, but no CLI flag loads them and the window's config: handler returns false unconditionally. The same is true of the four built-in themes and the styling layer. Build the command line from your script instead. See Configuration.

What is the equivalent of swiftDialog's default command file at a known path?

There isn't one. --commandfile requires an explicit path and the dialog creates the file and its parent directories if they are missing. Pick a path your script controls — a per-PID file under %TEMP%, or a working directory under %ProgramData% for a system-managed flow — and delete it before each launch, never during.

How do I make a window the user genuinely cannot dismiss?

Combine --button1disabled --hidedefaultkeyboardaction --quitkey 0. The first disables the button and refuses the title-bar X and Alt+F4; the second swallows Esc and Enter; the third leaves an operator one deliberate Ctrl+0 escape. Use --kiosk when it must also cover the screen with no escape at all — but then the only exits are a quit command and a timeout, so always give the script a finally that writes quit, and always pass a --timeout as a backstop.

Are the GitHub releases signed?

No. The release workflow deliberately omits the signing step, so every published MSI, .pkg, zip and executable is unsigned. Sign them with your own certificate before deploying — the recipe is in Installation and in the release notes themselves. Merging to main publishes nothing at all; only a v* tag cuts a release.

Does it need .NET installed on the endpoint?

No. Release artifacts are published self-contained, so the runtime ships in the payload. Building locally with plain dotnet build produces framework-dependent output; the packaging path in build.ps1 is what makes it self-contained.

Does it work on Windows 10 and on arm64?

Yes to both. Every release builds x64 and arm64. The only Windows-11-specific behaviour is the acrylic blur behind --fullscreen/--kiosk, which needs 22H2 or later; on older builds the DWM call fails silently and you get a plain dimmed backdrop.

Can I run it on a Remote Desktop or multi-session host?

It draws in whichever interactive session launched it, so per-session launches work. The fullscreen overlay sizes itself to the whole virtual desktop of that session. There is no mechanism for broadcasting one dialog to several sessions — launch one per session.

Where are the logs?

%ProgramData%\ManagedNotifications\logs\csharpdialog.log, rolling at 5 MB with five generations. It records process start with the full argument list, warnings, errors and the exit code. There is no verbosity switch. Command-file activity is narrated on stdout instead, which is also where the Result: line your script should parse appears.