I have a visual tree containing several TextField elements. One of these elements is intended to include a directory path. If the user types a path containing a backslash, then the backslash is interpreted as an escape character prefix. For example, the path “C:\temp” treats the “\t” as a tab.
Is there a way to disable interpretation of backslashes as escape character prefixes in a TextField?
Just add another \ to escape the .
“\t”
“C:\temp”
Unforunately this does not solve the problem. The user is the one entering the backslash, so I can’t replace it in code.
Moreover, it appears to be a purely visual issue. The serialized property has the backslash properly escaped. It’s only in the visual display of the property that the tab appears.
Can you not get the input text and then replace "" with “\”
Here’s a screenshot of a TMPro rendering escaped 's… so it does work…
I’m not sure about the serialised property, maybe the serialiser is escaping it so that it serialises properly and it’s showing you the string post serialisation.
I just realised you said TextField. sorry I’ll double check that now.
By TextField, what do you mean? InputField component? The InputFeild component uses TestMeshPro Text(UI) components to display text. there’s a check box on them
‘parse escape characters’ under ‘Extra Settings’
I believe @beevik is talking about UI Toolkit’s TextField?
I don’t think we have built-in support for that at the moment. A workaround would be to register the value changed callback and replace escape characters by a double backslash version.
Here’s a quick example of what it could look like:
textField.RegisterValueChangedCallback(e =>
{
// Use regex to find and replace occurrences of escape characters in e.newValue
var value = e.newValue... replace "\\t" by "\\\\t"
textField.SetValueWithoutNotify(value);
// Need to change the cursor position with SelectRange because new characters are added.
textField.SelectRange(value.Length, value.Length);
});
Oh i see, my mistake.
This does not work for me.
I have a TextField to enter a path. This might be a windows path, thus it is likely to contain backslashes.
The following does not work:
C:\utils (\u is interpreted as start of a unicode character)
C:\tools (\t is interpreted as tab character)
C:\nuts (\n is interpreted as new line)
When doing a replacement of \ with \ then the text editing is messed up. User can remove a single slash, which leads to a single slash beeing left, which leads to messed up display of text value again.
How to prevent this issue more properly?
Well, for now a workaround that works for me is to replace back-slash with another single character.
Looks stupid on Windows but at least this works with UIToolkit InputField.
string backslashReplacement = "＼"; // FULLWIDTH REVERSE SOLIDUS
textField.RegisterValueChangedCallback(evt =>
{
string newValueEscaped = evt.newValue
.Replace("\\", backslashReplacement);
string newValueUnescaped = newValueEscaped.Replace(backslashReplacement, "\\");
folderPath = newValueUnescaped;
textField.SetValueWithoutNotify(newValueEscaped);
});
textField.value = folderPath.Replace("\\", backslashReplacement);
Because it is still a single character, the text editing works as before.
Here are some more Unicode backslash alternatives: https://unicode-search.net/unicode-namesearch.pl?term=BACKSLASH
“SMALL REVERSE SOLIDUS” and “FULLWIDTH REVERSE SOLIDUS” are the only proper candidates. Sadly, they both look stupid in the TextField.
It seems strange that UI Toolkit’s TextField doesn’t handle backslashes in a natural and expected way. Is this something that’s being looked at for possible improvement?
We are tracking this, and UI Toolkit will expose a “Parse Escaped Characters” as TMP does in the near future.
Thanks for bringing this up!
Holy hell. This is such an insane default behavior to apply to all text rendering in UIs. How is this not higher priority??
We are being forced to SANITIZE ALL OUR INPUT, INCLUDING OUR OWN LABELS, and then ROUND TRIP UN-SANITIZE TEXT AS IT COMES OUT.
This is such a huge blocker to literally anyone trying to use input elements for ANYTHING. The current behaviour is almost fully unusable in any case with a . The workaround above has enormous downsides and has to be implemented on every single control.
Who’s idiotic idea was this?
Since unity supports paths with forward slash on all devices, perhaps implementing the change callback above would work by replacing the entered backslash with a forward slash?
Hi all! We finally addressed this issue in 2023.1, sorry for all the new grey hairs this issue might have caused. So as 2023.1, escape sequences are no longer interpreted by default. Be aware that this is a behaviour change and that may impact some of the fixes mentioned above so be mindful of this when upgrading. To keep interpreting “escape sequences”, we have exposed a new property accessible to all TextElement called parseEscapeSequences. This property is also accessible through the UI Builder.
Note that as this is a behaviour change, so we don’t intend to backport this to earlier versions.
Thanks for fixing this. I’m a little disappointed it won’t be backported to LTS. Could it be backported with an input system setting to enable it? That way it wouldn’t change the behavior of existing projects.
Hi @beevik ! This should be doable. We could expose the property in previous versions and only change the default value in 2023.1. Can you log a bug through the Unity Bug reporter for this? It would help a lot to get it backported.
Thanks for your input!
Done. Case # is IN-13629
Hi @beevik , I’m struggling with the same issue and I don’t find the bug in unity issuetracker. Can you post the link here please, so people can vote?
The case # is a Unity-internal bug tracking number. I don’t believe there is a public-facing one.
Hi! I opened a public ticket. Feel free to vote on it, it helps get the backport prioritized.
I’ve tested this issue in Unity version v.2022.2.18 and still persists.