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]
#rb Chris.Gagnon, Johan.Berg
#preflight 629f7017617cbe81d32add99
#ushell-cherrypick of 20541559 by Patrick.Laflamme
#preflight 629fbb4b521254896f6c2c43
#ROBOMERGE-AUTHOR: patrick.laflamme
#ROBOMERGE-SOURCE: CL 20546605 via CL 20546619 via CL 20546630 via CL 20546644 via CL 20546648
#ROBOMERGE-BOT: UE5 (Release-Engine-Staging -> Main) (v954-20466795)
[CL 20552343 by patrick laflamme in ue5-main branch]
The previous default of CanBeUsedOnAnyThread() proved unsafe since some output devices can safely be used on any thread but cannot safely be used during a crash. CanBeUsedOnAnyThread() was used pre-5.1 to control serialization to an output device during a crash, but optimizations in 5.1 have uncovered that some of these were never safe.
#preflight 62856506614041edb7a6de4b
#rb Zousar.Shaker
#rnx
[CL 20280354 by Devin Doucette in ue5-main branch]
### Features
This change enables the StallDetector watchdog in Editor to submit reports to crashreporter about threads violating instrumented deadlines in the source code. This feature was available prior on Windows, and this change adds Linux support.
### Notes
New APIs:
ReportStall()
CaptureThreadPortableCallStack()
Many APIs are updated from purely "Ensure" naming to more general naming. Stalls are more like Ensures than crashes, and so the appropriate renames to make the code readable and clear have been made. In some places Ensure is replaced with the clearer: Continuable Event nomenclature.
### Testing
I synthesized an ensure on Linux, and did the same for a stall. I then compared crash report XML file to make sure they contain accurate data in the callstack, portable callstack, and other fields in the report. I also noted that the stall information was showing as expected in the crash reporter.
#rb brandon.schaefer, francis.hurteau
#jira UETOOL-3336
#preflight 625e20d2804460ab0fea3277
[CL 19911608 by geoff evans in ue5-main branch]
Panic allows only one thread to become the panic thread. In panic mode, logs are only sent to panic-safe output devices. Each call to Panic flushes buffered logs to panic-safe output devices, and flushes panic-safe output devices.
#jira UE-147152
#preflight 62424814292f228e09d8a612
#rb Zousar.Shaker
#fyi Brandon.Schaefer
[CL 19545093 by Devin Doucette in ue5-main branch]
- Ensured the new FTSTicker get ticked when running CRC in unattended mode.
#rb Jerome.Delattre
#fyi Dmytro.vovk
[CL 17157164 by Patrick Laflamme in ue5-main branch]
- The data show no evidence that CRC is crashing there. Capturing this state is I/O expensive and not required moving forward.
#jira UETOOL-4042 Inspect UE5/Main analytics for CRC crashes
#rb Jamie.Dale
[CL 17116844 by Patrick Laflamme in ue5-main branch]
