Reject the name of an existing list in the assembly list prompt - #4129
Merged
Conversation
The WPF host kept the name prompt open and said the name was taken; the port kept the resource string but dropped the message, and the New / Clone / Rename / Add-preconfigured handlers only return early on a collision. Nothing tells the user why the list they just named did not appear, which reads as the dialog having accepted the name. The check belongs in the prompt, where the name is entered: OK stays disabled while the name collides, so no flow can be handed one. Rename passes the name of the list being renamed as allowed, because that is a no-op rather than a collision with itself. Assisted-by: Claude:claude-opus-5:Claude Code
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
1 participant
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.
The Manage Assembly Lists dialog does not prevent naming a new list after an existing one. All four flows (New / Clone / Rename / Add preconfigured) do check
manager.AssemblyLists.Contains(name), but only toreturn-- the prompt closes, nothing happens, and nothing says why the list never appeared. The WPF host kept the prompt open and showedResources.ListExistsAlready; the port kept the resource string and dropped the message.The check now sits in the prompt itself, where the name is entered:
CreateListDialogtakes a predicate for "is this name in use", keeps OK disabled while the name collides, and shows that same resource string. Since all four flows go through the one prompt, all four are covered. Rename passes the name of the list being renamed as allowed -- renaming a list to its own name is a no-op, not a collision with itself. The early returns in the handlers stay as a second line of defence; they are simply no longer reachable through the UI.Two headless tests cover the collision and the rename-to-itself case.
Button.RootDefaultKeyDowngates onIsEffectivelyEnabled, so the disabled OK cannot be triggered with Enter either.Full
ILSpy.Testsrun: 1277 tests, 0 failures.This PR was prepared by an AI agent (Claude Code) on my behalf.