Handle multi-byte characters correctly in text fields - #10194
Open
hard25670559 wants to merge 1 commit into
Open
Handle multi-byte characters correctly in text fields#10194hard25670559 wants to merge 1 commit into
hard25670559 wants to merge 1 commit into
Conversation
Two independent defects made non-ASCII text unusable in EditControl. Pasting replaced every byte >= 0x80 with "?" before inserting. In a field carrying a filename filter the "?" was then stripped again as an illegal character, so pasted text disappeared outright rather than merely being mangled. Drop the substitution and let the bytes through; Insert() still applies the control's own filter. Backspace and delete removed a fixed single byte, which splits a multi-byte character and leaves an invalid sequence behind. Caret movement already steps by whole characters through utf8.next, so deletion now derives its length from the same helper. The ctrl-modified word-wise paths are untouched.
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.
Description of the problem being solved
Two independent defects in
EditControlmake non-ASCII text unusable, regardless of platform or language.Pasting discards the text entirely. Every byte
>= 0x80is replaced with"?"before insertion:In a field carrying a filename filter (
\\/:%*%?\"<>|%c), those"?"are then stripped again byInsert()as illegal characters. The result is not mangled text but no text — pasting a build name, folder name or item appears to do nothing at all.Backspace and delete corrupt the text. Both remove a fixed single byte:
A multi-byte character is therefore cut in half, leaving an invalid sequence that renders as
?. Caret movement already steps by whole characters viautf8.next, so the two behaviours disagree: the caret moves over a character but deleting only removes a third of it.Related: #5632 (open since 2023, "POB currently cannot input languages other than english"), and #6669, which relaxed the default input filter under PoeCharm but did not address paste or deletion.
Description of the changes
Insert()still applies each control's own filter, so filename-illegal characters are still rejected — only the blanket replacement of non-ASCII is gone.utf8.next, the same helper caret movement already uses, so a keystroke removes exactly the character the caret moved over. The ctrl-modified word-wise paths are unchanged.Both changes are platform-independent and affect any language that uses characters outside ASCII.
Steps taken to verify a working solution
Tested on macOS with Traditional Chinese text in the "Save As" build name field:
測試中文previously left the field empty; it now inserts the text, and saving produces a file named correctly on disk.?behind after the first; it now removes one whole character per press (卡在這→卡在→卡).The fields still need engine-side font support to display these characters; that is separate and not part of this change.