Official Important Message Related to the TextField Refactor for 2022.1+.

Thank you for bringing UIToolkit one step closer,
TMPro Input Field have limitations on mobile, so please along with feature parity also take care of solving those limitations so we can have better player chat in our mobile game due to improved input field that provide text selection, mobile native auto correct, and "ideally" a visual rich text editor

 

Is there any chance this will make it back into 2021LTS? If there's one thing I need fixed it is the TextField and I was really hoping there'd be an answer 2021.2.

 

I have a bunch of needs from it but the big one is to be able to edit field focus in code.
I need a text field which only gets focus when the player clicks on it and always loses focus when the player confirms they are done editing.
The current text field grabs focus whenever a character is typed. Unfortunately that means it grabs focus when, for instance, the player is navigating the world with the WASD keys and the field gets filled with gibberish. The way I attempt to handle this is to disable the text field when its not in "edit mode" and then enable & focus it on a click. However the focus doesn't take and currently it takes two clicks to actually enter text--the first when enables the text field and the second which focuses it.

While I am adding wishes--I layout my screen using a larger coordinate system than the screen and set the "Panel Settings" to scale it to match the screen. However the text field uses a single point wide rectangle for the vertical bar and, when scaling, that regularly aliases down to zero pixels and vanishes.

I was hoping that the TextField was going to be stable in 2021LTS, but now it looks like its 2022 which is too far out for me. Currently I am contemplating writing my own or else grabbing the code out of the package and forking it so I can make something that works for me. Is going to be any way to positively control TextField focus in 2021 or am I on my own for this?

 

While I love that the text development is continuing, I can't say I'm glad about the inclusion of the scrollbar/scrollview in the textfield.

This very thing causes me lots of issues with the original tmpro, as the text is then also responsible for scrolling and makes a bunch of assumptions about how and when that should work. It makes every use case but the standard one more difficult and also complicates nesting tmpro_inputfields in scrollviews. Want text with horizontal scroll only? Want scrolling that syncs with input? Want selection but no scrolling? Want a different start point for the scroll bar or a different scroll direction? Want to manipulate the scrollpoint in some way? Want to disable scrolling in certain situations? All these things and more become more complicated and you have to learn several ways to solve them. Want to configure a scrollbar for some text element? Your normal scrollbar knowledge is no good, better learn how to access the scrollbar through the text element, investigate the source code to find out how tmpro wants the scrollbar to be used and when it accesses/changes its properties. Also be prepared to fight or fork tmpro elements if you have anything planned that doesn't align with its vision of scrolling.

=> Scrolling content and rendering text are two different concerns, so I'm not convinced it is wise to have the text rendering element have strong opinions/knowledge/dependencies about how it is scrolled. I hope this separation will be cleaner here than it is in the original tmpro.

Another point, since font assets were mentioned. I would be amazing if tmpro could also give us a cleaner cut in terms of generated and static assets. Having assets be half generated and half static (I'm looking at dynamic font atlas features in particular) frequently causes small, but entirely avoidable mistakes (mostly to do with versioning).

 

Hi @hugobd ,
Thank you for your quick response

A quick and dirty overview of the way tmpro does it:
The inputfield itself does the scrolling/hides its scrolling parts from the outside. You can set a vertical scrollbar and do some configuration, but the component itself has a strong/hardcoded opinion about how that scrollbar is used/how it wants to be scrolled. So if your use case doesn't exactly align with that, be prepared to dive into that tmpro source code (to either modify it or time your edits right after tmpro does them, which is sketchy at best).

The scrollview itself being queryable does help I think. Still I am sceptical about a couple of points here:

- Yes the current (and the original tmpro) textfield properties do not allow for the flexibility I'm looking for, but as you've said the native scrollview supports all that. I'm not advocating putting all scrollview properties into the textfield, I'm advocating putting none of them in there (not even the scrollview itself), because I'm not convinced the textfield should care about how it is scrolled at all.

- Why put this at the textfield level? Why would a textfield have the ability to be scrolled, but a textlabel does not? Why wire the ability to get scrolled into one kind of text object. Why wire it into any specific object at all? Why should a textfield be scrolled differently than a textlabel or any other object?

- As far as I'm concerned a Textlabel just renders text in a container (and allows read interactions: select text, copy, etc.). A textfield extends this to allow write interactions (and placeholders). A Masking component limits rendering of a container to its region and a Scrolling component decides where on the container an object (the masking region in this case) resides. I don't see much reason for hard coding/intimately wiring all of these parts together (except maybe performance considerations, but even then I'm not convinced the text component should have opinions/set things like scroll direction etc.).

- In your post you point out that you believe there are better ways to achieve modularity/flexibility than embedding a textfield into a scrollview. I am curious what you had in mind here? Writing custom text components to change things like scroll direction does not seem very modular/flexible to me.

Thanks for reading through my questions/concerns

 

Hi @hugobd
We just lost Advanced TextInput Field 2 for uGUI, so my question is, is UI Toolkit based Text Input works on mobile with caret selection and features such as auto suggest / auto fill?
If not, any plans for that?

 

I dont think feature parity alone will solve it, we atleast need 2 things in mobile input field
1- caret selection or ability to tap and any where in text and change it rather than deleting whole text
2- auto suggest/remember feature

So please please please, consider this

 

If I want to focus to the TextField in code, I’d expect that I could call `textField.Focus()`. It seems to get the focus (the border color of the input field changes, in the editor a cursor appears) but when I build this to my mobile device no keyboard is shown!

This is a real problem and a regression from the old TextField which worked as expected and which we are wrapping in a custom component and call focus from there.

To add a question:
1. Is this a bug or the new intended behavior?
2. Is there a way to manually force showing and/or hiding the soft keyboard on Android/iOS?

 

Thanks, @freddycheungh, for the answer! What about closing the soft keyboard?

 

@hugobd Can I scroll to last position by using script? I'm trying to implement console-log like UI which shows latest message automatically, but I can't find the way.

 

We are noticing some issues since we switched from 2021.2.19 to 2022.1.0:

For example, I had to manually add:

Code (CSharp):

1. TextInput .unity-scroll-view--inner-input-field-component {
2.     flex-grow: 1;
3. }

To have the TextInput fill the TextField. I also noticed that the TextElement inside the TextField doesn't fill the width of the TextField.

What is also really weird, is that we're using the Unity default runtime theme (and the same version of Unity), but on my machine, this seems to contain the flex-grow: 1; that I mentioned above, while for my colleagues, this is missing. How is that possible?

 

Hi, thanks for the reply! I asked my colleague that had a different version than me to do this Reimport and it was fixed. However I would like to commit this to our repository such that it is fixed for everyone but I don't see any code changes after the Reimport. What files does this reimport affect? How can I solve this generally for the repository?

 

That doesn't really answer my question. Now, every colleague working on our Unity application has to manually Reimport this asset, my question is whether it's possible to do this Reimport automatically?

 

Hi @hugobd , thanks for the reply. We are on version 2022.1.0 at the moment.

I was indeed checking the asset but didn't see any code changes, that is the strange part but if it's fixed, I'll perhaps wait and see whether it occurs again.

 

I tried using the new TextField today and ran into some issues:

The scrollbar only seems to work from the inputfield to the scrollbar, not the other way round.
What I mean is: When I add or remove text, the scrollbar gets updated. But when I click on the buttons of the scrollbar or drag the scrollbars-dragger, the textfield is not updated.

 

I'm currently using the Textfields and where the vertical scrollbar does its thing. What about a horizontal scrollbar or an option to detect the text is reaching the width of the textfield? Right now the user can keep adding text quite infinitely horizontally. I would like to build some logic to automatically insert a new line when the end of the TextField width is reached. Is something like this already possible or is this something that can be added?

 

Hi @hugobd,

Whitespace.normal was exactly what I was looking for! Thank you for mentioning it. The reason for a horizontal scrollbar would be for UI toolkit at runtime. At this moment I am making a form where users input their name, email and some additional information. When I don't use Whitespace.normal a textfield that contains a lot of text on the same line doesn't show that to the user. Also the user can't easily scroll back to the beginning to edit something in the textfield. For my current use case the textfield user uses a custom on screen keyboard to input their data. This means they can't use a mouse and then a scrollbar would improve the UX for touchscreen users a lot.

For now I can use Whitespace.Normal, but having the option later for enabling a dynamic horizontal scrollbar for runtime would be highly appreciated.

 

I ran into more issue which happen when I use the TextFields ScrollView or enbed the TextField on a screen with its own ScrollView:

When the ScrollView is all the way up you can select text without problems. But when you scroll down a bit and the try to mark text, the ScrollView scrolls all the way up to the top.
And marking is all jerky from here (sometimes it marks text without me keeping the mouse pressed, or marks the whole text).

This all happens in my project and also in clean projects wiith only standard style and no code.

I use Unity 2022.1.7

 

I tried this but unforunatelly it did not fix the bug.
It seem that when you hold the mousebutton and move it to the right (to mark the text), the scrollView gets somehow the order to scroll to the top.

I have some more information:
When I downgrade to 2022.1.6 the bug is gone. So it seams that some changes in 2022.1.7 broke it.

 

Done
IN-9636

 

@hugobd ,

What did you think of my use case for a horizontal scroller for a textfield? Is it something that is quite easily implemented or is it maybe put into consideration to add?

Thanks in advance!

 

Hello!

I may have simply missed this, but is there (soon) an equivalent to this option in TMPro's Input Field?

I can't seem to disable this behavior for my UITK Text Field - every time I focus my text, it gets selected in its entirety.

 

There is selectAllOnFocus and selectAllOnMouseUp on TextInputBaseField (see https://docs.unity3d.com/2022.2/Documentation/ScriptReference/UIElements.TextInputBaseField_1.html). Is that what you're looking for?

 

Ah, thank you! I think I'm still getting used to this not being a package on its own, so I was working with 2021 LTS, where that didn't exist yet.

 

Hi,

For the multiline textfield, we would like to change the behaviour on enter. Instead of adding a newline to the text, we would like to submit the text. On shift+enter it should add a newline. I tried to achieve this by overriding

protected override void ExecuteDefaultActionAtTarget

but this doesn't seem to work.

How can I do this? Or is this not possible?

Thanks! Chloë

 

Nice! Made a few adjustments but this is indeed exactly what I needed, thanks a lot!

 

I'm trying to create a code field element that inherits from TextField.
I faced the following problems:
- I cannot access ScrollView in a constructor even after setting `multiline` to true and calling `
SetVerticalScrollerVisibility`. There doesn't seem to be any way to configure the inner scroll view in the element constructor.
- I also want to configure and use a horizontal scroller as well, there is no API for that

 

Thanks, for the tips, I'll be fine without the rich tags for now
Could we get easier access to the inner scroll view? It would be a guessing game for the developer to find out that he can only access it on the next frame.

 

Hey this me again

I need to return focus to the input field after sending the message (after pressing return) - what is the right way to do this?

If I use the command "textField.Focus();" , then it looks like the Unity does not focus the input field, but its parent component.

P.s. I'm not sure if it's right to ask about this in this thread or would it be in future better to create a new one?

P.P.s. Unity 2022.2.1f1