- Resolves issues where the FReply living on ULocalPlayer could cause SObjectWidgets and their associated UUserWidgets to have a delayed destruction process.
- Also just generally stands to reason that if the FReply reference is the only thing keeping a widget alive, there's no chance that SlateApplication will actually be able to do anything meaningful with that widget anyway (it can't be focused, captured, dragged, etc.)
- Resolved a lurking potential crash in FSlateApplication that was made more possible by this change
[at]Nick.Darnell
#ROBOMERGE-SOURCE: CL 10379330 via CL 10380129 via CL 10380157
#ROBOMERGE-BOT: (v594-10333955)
[CL 10380670 by dan hertzka in Main branch]
- Added FSlateUser::IsWidgetInFocusPath() and added some comments explaining the three different functions there for checking focused-ness of a widget
#ROBOMERGE-SOURCE: CL 10282945 via CL 10282946 via CL 10282947
#ROBOMERGE-BOT: (v591-10236483)
[CL 10282948 by dan hertzka in Main branch]
These can be used to validate whether a font supports certain characters and glyphs.
[FYI] Jamie.Dale
#rb Jamie.Dale
#ROBOMERGE-SOURCE: CL 10060107 via CL 10060109 via CL 10060112 via CL 10060113
#ROBOMERGE-BOT: (v566-10053404)
[CL 10060114 by stephan jiang in Main branch]
#Jira UE-75661
#rb jeff.newquist
#ROBOMERGE-SOURCE: CL 9907013 in //UE4/Release-4.24/...
#ROBOMERGE-BOT: RELEASE (Release-4.24 -> Main) (v558-9892490)
[CL 9907099 by john white in Main branch]
#jira UE-82383
#rb chris.gagnon
#ROBOMERGE-SOURCE: CL 9873043 in //UE4/Release-4.24/...
#ROBOMERGE-BOT: RELEASE (Release-4.24 -> Main) (v548-9842178)
[CL 9873096 by rex hill in Main branch]
The unbounded rect caused a serious performance regression in FreeType 2.10 when compared to FreeType 2.6 (which did this clamping internally).
#jira FORT-224368
#rb Matt.Kuhlenschmidt
#rnx
#ROBOMERGE-SOURCE: CL 9841489 in //UE4/Release-4.24/...
#ROBOMERGE-BOT: RELEASE (Release-4.24 -> Main) (v546-9757112)
[CL 9841499 by jamie dale in Main branch]
Matt.Kuhlenschmidt
#ROBOMERGE-SOURCE: CL 9421835 via CL 9421841 via CL 9421844 via CL 9421851 via CL 9422758
#ROBOMERGE-BOT: (v480-9420520)
[CL 9423104 by nick darnell in Main branch]
#ROBOMERGE-SOURCE: CL 9388509 via CL 9388536 via CL 9388543 via CL 9388574 via CL 9388597
#ROBOMERGE-BOT: (v456-9359915)
[CL 9391943 by nick darnell in Main branch]
Replicated from CL# 7924370.
#rb none
#ROBOMERGE-OWNER: steve.robb
#ROBOMERGE-AUTHOR: steve.robb
#ROBOMERGE-SOURCE: CL 9279060 via CL 9279063
#ROBOMERGE-BOT: (v443-9013191)
[CL 9279836 by steve robb in Main branch]
Most UE4 platforms use a 2-byte TCHAR, however some still use a 4-byte TCHAR. The platforms that use a 4-byte TCHAR expect their string data to be UTF-32, however there are parts of UE4 that serialize FString data as a series of UCS2CHAR, simply narrowing or widening each TCHAR in turn. This can result in invalid or corrupted UTF-32 strings (either UTF-32 strings containing UTF-16 surrogates, or UTF-32 code points that have been truncated to 2-bytes), which leads to either odd behavior or crashes.
This change updates the parts of UE4 that process FString data as a series of 2-byte values to do so on the correct UTF-16 interpretation of the data, converting to/from UTF-32 as required on platforms that use a 4-byte TCHAR. This conversion is a no-op on platforms that use a 2-byte TCHAR as the string is already assumed to be valid UTF-16 data. It should also be noted that while FString may contain UTF-16 code units on platforms using a 2-byte TCHAR, this change doesn't do anything to make FString represent a Unicode string on those platforms (ie, a string that understands and works on code points), but is rather just a bag of code units.
Two new variable-width string converters have be added to facilitate the conversion (modelled after the TCHAR<->UTF-8 converters), TUTF16ToUTF32_Convert and TUTF32ToUTF16_Convert. These are used for both TCHAR<->UTF16CHAR conversion when needed, but also for TCHAR<->wchar_t conversion on platforms that use char16_t for TCHAR along with having a 4-byte wchar_t (as defined by the new PLATFORM_WCHAR_IS_4_BYTES option).
These conversion routines are accessed either via the conversion macros (TCHAR_TO_UTF16, UTF16_TO_TCHAR, TCHAR_TO_WCHAR, and WCHAR_TO_TCHAR), or by using a conversion struct (FTCHARToUTF16, FUTF16ToTCHAR, FTCHARToWChar, and FWCharToTCHAR), which is the same pattern as the existing TCHAR<->UTF-8 conversion. Both the macros and the structs are defined as no-ops when the conversion isn't needed, but always exist so that code can be written in a portable way.
Very little code actually needed updating to use UTF-16, as the vast majority makes no assumptions about the size of TCHAR, nor how FString should be serialized. The main places were the FString archive serialization and the JSON reader/writer, along with some minor fixes to the UTF-8 conversion logic for platforms using a 4-byte TCHAR.
Tests have been added to verify that an FString representing a UTF-32 code point can be losslessly converted to/from UTF-8 and UTF-16, and serialized to/from an archive.
#jira
#rb Steve.Robb, Josh.Adams
#ROBOMERGE-SOURCE: CL 8676728 via CL 8687863
#ROBOMERGE-BOT: (v421-8677696)
[CL 8688048 by jamie dale in Main branch]
