Add swiftDialog lock parity: --button1disabled, --quitkey, --hidedefaultkeyboardaction#1
Merged
Merged
Conversation
…boardaction Adds the dismissal-control surface needed to run csharpDialog as a locked provisioning progress window, matching how swiftDialog is driven on macOS: - --button1disabled renders button1 disabled and engages a close lock: the title-bar X and Alt+F4 refuse to close the window until a legitimate dismissal path runs (quit command, quit key, timeout, or a runtime 'button1: enable' followed by a click). - --quitkey <char> makes Ctrl+<char> close the dialog (Windows analog of swiftDialog's Cmd-based quit key). - --hidedefaultkeyboardaction suppresses Esc, Enter, and Alt+F4. - Command file gains 'button1: enable|disable' (toggles the button and the close lock together) and 'button1text:' is now actually applied to the footer button; both were parsed but unimplemented. - --button1text/--button2text accepted as CLI aliases of --button1/--button2; the README documented them but the parser did not accept them. - Timeout and quit paths set AllowClose so they keep working under the lock. Compile-validated with dotnet build -p:EnableWindowsTargeting=true (CLI and WPF projects, zero warnings).
There was a problem hiding this comment.
Pull request overview
This PR adds “locked / non-dismissable” dialog behavior to the WPF progress window to match swiftDialog’s provisioning UX, plus related command-file and CLI parser enhancements.
Changes:
- Add close-locking and keyboard-dismiss suppression (
--button1disabled,--hidedefaultkeyboardaction,--quitkey) to the WPF dialog. - Implement previously-recognized-but-inert command-file commands (
button1text:,button1: enable|disable) and add CLI aliases for button text options. - Document the new lock/dismissal controls and the new command-file behaviors in the README.
Reviewed changes
Copilot reviewed 6 out of 6 changed files in this pull request and generated 5 comments.
Show a summary per file
| File | Description |
|---|---|
| src/CsharpDialog.WPF/Services/WpfDialogService.cs | Implements close locking, quit-key handling, keyboard suppression, and button1 command support in the WPF service. |
| src/CsharpDialog.WPF/ProgressDialogWindow.xaml.cs | Adds AllowClose gate and sets it on button click for lock-compatible closing. |
| src/CsharpDialog.Core/Services/CommandParser.cs | Extends valid command set (button1/button2) for command-file parsing. |
| src/CsharpDialog.Core/DialogConfiguration.cs | Adds configuration knobs for lock/dismissal control options. |
| src/CsharpDialog.Core/CommandLineParser.cs | Adds CLI aliases and new lock/dismissal flags. |
| README.md | Documents new lock/dismissal controls and button1 command-file usage. |
💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.
Comment on lines
+24
to
+28
| // True while button1 is disabled: the window refuses to close via the | ||
| // title-bar X or Alt+F4 until a legitimate dismissal path sets | ||
| // _window.AllowClose (quit command, quit key, timeout, button1: enable | ||
| // followed by a click). swiftDialog --button1disabled parity. | ||
| private bool _closeLocked = false; |
Comment on lines
+148
to
+154
| if (okButton != null) | ||
| { | ||
| var button1 = configuration.Buttons.FirstOrDefault(b => b.Action is "button1" or "ok"); | ||
| if (button1 != null && !string.IsNullOrEmpty(button1.Text)) | ||
| okButton.Content = button1.Text; | ||
|
|
||
| if (configuration.Button1Disabled) |
Comment on lines
+14
to
18
| "executeoutput", "width", "height", "position", "icon", "image", "button1text", "button2text", | ||
| "button1", "button2" | ||
| }; | ||
|
|
||
| /// <summary> |
Comment on lines
+58
to
+64
| case "--quitkey": | ||
| if (!string.IsNullOrEmpty(value)) | ||
| { | ||
| config.QuitKey = value; | ||
| i++; | ||
| } | ||
| break; |
… normalization - Attach the Closing gate unconditionally so a runtime 'button1: disable' command actually enforces the close lock, not just the startup flag. - Accept bare valid-command lines (no colon) in the command file parser so the documented 'quit' form works; it was previously rejected, meaning the documented close path never fired. - Record the configured button1 action in DialogResult.ButtonPressed on click instead of always reporting the default 'ok'. - Normalize --quitkey to its first character at parse time. - Fix the close-lock field comment to match the actual release behavior (released immediately on 'button1: enable').
Contributor
Author
|
All five review comments addressed in bb76df4:
Both projects rebuild clean with |
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Why
We drive csharpDialog as the Windows provisioning progress window (BootstrapMate userland → ProvisioningWatcher.ps1), the counterpart of swiftDialog in our macOS workflow. The Mac dialog runs locked — non-blocking but undismissable:
--button1disabled,--hidedefaultkeyboardaction, and--quitkeyremapped off the reflexive quit chord. csharpDialog had none of these, so the Windows window could be closed with X / Alt+F4 / Esc mid-provisioning.What
--button1disabled— renders button1 disabled and engages a close lock: title-bar X and Alt+F4 are refused until a legitimate dismissal path runs (quitcommand, quit key, timeout, or a runtimebutton1: enablefollowed by a click). Implemented via aClosinggate + anAllowCloseflag set by every legitimate path.--quitkey <char>— Ctrl+<char> closes the dialog (Windows analog of swiftDialog's Cmd-based quit key; letters and digits).--hidedefaultkeyboardaction— suppresses Esc, Enter, and Alt+F4 viaPreviewKeyDown.button1: enable|disablenow toggles the footer button and the close lock together, andbutton1text:is actually applied (both were inValidCommands/recognized but unimplemented).--button1text/--button2textaccepted as CLI aliases — the README documented them but the parser only accepted--button1/--button2.button1:command-file docs.Typical locked provisioning window
then from the controlling script on completion:
Validation
dotnet build -p:EnableWindowsTargeting=trueon Core, CLI, and WPF: clean, zero warnings.Closingprevention is untouched; the new lock is an independent handler.Out of scope
button2has no UI inProgressDialogWindow(single footer button), sobutton2text/button2: enableremain parsed-but-inert — left for a follow-up if a second button is added.