I noticed after updating to 5.1 that setting a text field with nothing (to clear it) no longer works, and instead it preserves whatever text was present before the text is committed
3 Likes
1 Like
If your text field starts empty, and you input text into it at runtime, then it doesn’t work. What you are doing there is already populating the text field before clearing it with the false branch SetText.
To reiterate:
- if the text is set from within the editor, and you clear it at runtime = works
- if you SetText at runtime with something, then clear it, which is what you are doing = works
- if you start with an empty text field, write stuff into it via keyboard, then clear it on commit = broken
1 Like
The code reveals your problem
void UEditableText::SetText(FText InText)
{
// We detect if the Text is internal pointing to the same thing if so, nothing to do.
if (Text.IdenticalTo(InText))
{
return;
}
Text = InText;
/// etc .....
}
Because you are not setting it after the commit it always sees it as empty (because you are not passing in the value).
so it triggers
if (Text.IdenticalTo(InText)){ return; }
So it does nothing.
The only way for it to work is the double set first with value second with none.
This didn’t use to be the case and it is very unintuitive. Why even need to check it first? Why not just set it to nothing and move on.
SetText should just set the text without validating it. The check doesn’t make any sense there
It’s an optimization (if nothing changes then don’t change the text)
Committing the editable text field is just an event, it doesn’t set the text value internally, so yes you have to change it manually for it to take effect.
It only updates if it changes
Then is this the case for other set variable types? As far as i know this is the way you are supposed to invalidate (nullptr) a class or clear a string.
@VL4DST3R But you need to set it to something first…it’s empty
Optimizations should be made only if they don’t break functionality. In this instance if you have an initially empty text and expect the user to input something and have the text clear itself just using one node it doesn’t work anymore, hence any game that uses this method can’t update the engine version without breaking the game
Yes but again, i’m asking if this behavior in of itself, the skipping of actually setting the thing to what i ask it to, is now present everywhere else? As it didn’t use to be the case.
yeah, basically, or having to go everywhere and set stuff before unsetting it, which feels like anything but an optimization.
@Hynade you don’t understand the underlying mechanics
- start the field is empty.
- user types in field (internal value is still empty due to no setText being activated)
- user fires commit event not setting value
- code sees empty == empty so it does nothing.
You can probably fix it by binding the on change function setting the text of the editable field.
I understand how it works, I am trying to explain why it is OBJECTIVELY wrong… The internal text field should be updated BY DEFAULT OnTextChanged for the validation to make sense and not lose functionality. The current solution is the same if not a worse performance hit as not having a validation there at all.
Here is the code from 5.0.3, no checking of duplicate value
void UEditableText::SetText(FText InText)
{
Text = InText;
if ( MyEditableText.IsValid() )
{
MyEditableText->SetText(Text);
}
}
5 Likes
THIS! Why change something that’s not broken… I knew i wasnt crazy.
Created a pull request for this problem:
https://github.com/EpicGames/UnrealEngine/pull/9824
1 Like
I agree with VL4DST3R.
Changing this is extremely stupid, and have broken all my chat systems!
Now i had to make a stupid bypass, (inspiration taken from this thread)
Simply adding a “.” and then removing it so fast the user don’t see it. It’s to say the least, Dumb.