It was the initial bug, but while looking at it, I noticed that the MultilineEditableTextBox was containing both a Font via FEditableTextBoxStyle, and another one via FTextBlockStyle, thus being error prone / inconsistent.
In order to fix the underlying issue (in addition to fix the initial bug), I removed the Font from FEditableTextBoxStyle, and moved the FTextBlockStyle from MultilineEditableTextBox to FEditableTextBoxStyle.
It solves the duplication issue and so make it clear where the Font should be set/read from.
However, as the text block style is now embedded in the editable text box style, it cannot be initialized the exact same way, and I had to do some changes to ensure there was no regression, by configuring various FEditableTextBoxStyle in some style files. I also change the default value for TextBlockStyle to better match our default theme.
-Default font is not set for text widgets.
EditableWidget: ensure to have a default font, and to set the style when calling SynchronizeProperties to ensure it reacts directly without having to force a refresh (by moving the widget for instance)
Bonus:
-Move to cpp some private methods that where 'forced' inline (and we were using function pointer on them). It will avoid some noise in public interface and speed up iteration / compile time when playing with them.
#jira UE-96464
#jira UE-137126
[RN] MultilineEditableTextBox was containing both a Font via FEditableTextBoxStyle, and another one via FTextBlockStyle, thus being error prone / inconsistent.The Font from FEditableTextBoxStyle has been removed, and the FTextBlockStyle moved from MultilineEditableTextBox to FEditableTextBoxStyle. It solves the duplication issue and so make it clear where the Font should be set/read from.
However, as the FTextBlockStyle is now embedded in the FEditableTextBoxStyle, it cannot be initialized the exact same way, and you can now configure the FTextBlockStyle of FEditableTextBoxStyle when creating one from scratch, by calling SetTextStyle on it.
Test
- created a Widget blueprint with different editable types combination: multiline or single line, box or no box.
-Validated that everything was reacting live as expected now.
-Created a blue print to set the text style and validated it was working.
-Create data with old version, then open it with updated version to validate that the visual was still the same and deprecation of style working as expected.
-checked different places in the editor using variation of editable text to ensure they were behaving as before (detail view, console command entry, comment on blueprint node).
#preflight 63344b9f110bb3721ef8aa77
[CL 22232366 by yohann dossantos in ue5-main branch]
Overview:
- An "override flag" is an inline toggle-style Boolean edit condition. These are implicitly set to true at runtime within the output struct value if any member that's bound to it is exposed as a visible input pin on a MakeStruct node.
- For context, the Property Editor implicitly sets an override flag to true at edit time when a member that's bound to it is enabled for editing. These members are not otherwise labeled/exposed for direct editing.
- An override flag is meant to signal to a system that the user wishes to use the bound member's value in place of the current value (whatever that may be) when the full struct value is applied. Examples: FPostProcessSettings, FMovieSceneSequencePlaybackSettings, etc.
Previous UX:
- All boolean edit conditions were being treated as override flags on a MakeStruct node.
- Any inline toggle edit condition that did not begin with "bOverride_" or whose suffix otherwise did not match another value member could be exposed as an input on a MakeStruct node.
- Override flags exposed as inputs would always be set to TRUE at runtime regardless of input if it was declared at the top of the struct and if a member value bound to it was also exposed as an input pin.
After this change:
- Only inline toggle edit conditions and legacy struct members that follow the "bOverride_" naming convention will be treated as an override flag on a MakeStruct node.
- Inline toggle edit conditions can no longer be exposed directly as an input on a MakeStruct node. The intent was to bring the MakeStruct node UX closer to parity with the Property Editor UX.
Additional notes:
- Members that follow the legacy "bOverride_" naming convention were already being excluded from the optional input pin set on MakeStruct nodes if another member property name also matched its suffix. These have historically been excluded from ALL optional pin sets that utilize any FOptionalPinManager subtype (regardless of node type), so there was no change here.
- Existing MakeStruct nodes that may have already exposed inline toggle edit condition members as input pins will now orphan those pins on load if connected or if set to a non-default value (true). The "correct" way to set an override flag is by choosing to expose a member that's bound to the override condition as an input.
- Existing BreakStruct nodes are unchanged currently. Meaning, inline edit conditions that don't follow the legacy "bOverride_" convention can still be optionally exposed as an output pin. This UX was preserved as existing Blueprint logic could conceivably rely on the value of an override flag.
- Only one implicit assignment is now emitted for each override flag binding. Previously, we were emitting one assignment statement per bound property, so it could result in redundant assignments to the same flag if more than one property was bound to it.
#jira UE-147873
#rb Ben.Zeigler, Sebastian.Nordgren
#preflight 632c7353c7791417aa87f3bf
[CL 22164359 by phillip kavan in ue5-main branch]
The regression was introduced a few weeks ago when fixing another bug.
The issue was that conversion functions (between float and string) using the current regionnal settings were introduced in the graph pins, but this kind of conversion is done in a lot of places and does not all support the different type of decimal separator ('.' or ','). So those conversion functions were not supporting the new format of decimal they were receiving.
Also, while the bug is mentionning issue with float, it was existing also for vector.
Bonus: remove a bit of duplicated code.
#jira UE-162993, UE-159512
#rb jamie.dale massimo.tristano patrick.boutot
#test In blueprint/niagara/material, played with node using float, vector, rotator, to ensure that everything was behaving as expected with 2 regional settings (english with '.' decimal separator, french with ',' separator).
Validated that the initial bug (selecting default value with the mouse but not changing it was adding an entry in the undo stack), was still fix.
#preflight 6329be440a4ad044de92d0c9
[CL 22094319 by yohann dossantos in ue5-main branch]
Another consequence of using doubles everywhere in Blueprints is that delegate binding can fail if a native delegate signature uses floats. The initial attempt at fixing this would update modify function pins in the current Blueprint to use PC_Float as a subcategory if it was used in a delegate binding. Unfortunately, this doesn't work if we're binding to a function in a different BP class. Attempting to fix up those functions would dirty several Blueprints, and likely confuse users.
The approach that we take here creates a proxy delegate function that matches the underlying signature. The proxy's function graph will then call the original bound function, which implicitly handles any double/float conversions. Additionally, we'll perform a "capture" of any actors that we need to call the bound function on. The compiler will add a new hidden property for the actor class, which we set in the original graph that had the bound delegate. The proxy function graph will then read this property when it calls the original function.
#jira UE-145634
#preflight 63191b1cb069eea9ab594ea2
#rb phillip.kavan
[CL 22087332 by dave jones2 in ue5-main branch]
This was a bug exposed because FPropertyRowGenerator previously ignored RequestRefresh() calls entirely, but now does a deferred refresh.
Since this was the only use of it, IEditableTextProperty and all its implementations have also had their RequestRefresh() methods removed.
[REVIEW] [at]jamie.dale, [at]vincent.gauthier
#preflight 632432a2cb23fcbbd8ef5dd2
[CL 22050354 by sebastian nordgren in ue5-main branch]
Removed redundant private include paths from build.cs files.
Fixed include paths to be relative to the private or public folders.
Hid or removed includes that reached into other private module folders.
Updated PublicInclude paths when necessary.
#jira
#preflight 631e283bec5b0c765fc0ffdb
[CL 21960084 by bryan sefcik in ue5-main branch]
Fixups for class features in the editor.
#jira UE-161932
#rb ben.zeigler
#preflight 631a55942b7fe03eb6c27d74
[CL 21903450 by Robert Millar in ue5-main branch]
Fixed Scalar Parameter and Vector node to avoid triggering a component value change transaction if the user only clicks on the textbox (without effectively changing the value).
Currently when the user clicks on a Scalar or Vector parameter text box and then simply deselects the node, a data change is erroneously detected and a transaction is pushed onto the Undo stack. This change fixes the logic that determines whether the value is actually changed, removing these spurious and redundant transactions.
#rb sebastian.nordgren
#jira UE-159512
#preflight 62ff9986f7404b55a326ce08
[CL 21457315 by massimo tristano in ue5-main branch]
Currently when the user clicks on a Scalar or Vector parameter text box and then simply deselects the node, a data change is erroneously detected and a transaction is pushed onto the Undo stack. This change fixes the logic that determines whether the value is actually changed, removing these spurious and redundant transactions.
#rb sebastian.nordgren
#jira UE-159512
#preflight 62fe4890200ff87e07bddf46
[CL 21442104 by massimo tristano in ue5-main branch]
