I just wanted to give you all a heads up for a change that will be coming in 4.8.
The FString passthrough functionality of SLATE_TEXT_ATTRIBUTE is deprecated as of 4.8, which means that you’re now going to get a deprecation warning when passing text to Slate as FString rather than FText.
Here’s a couple of guidelines to help with this transition.
1) Do not use SLATE_TEXT_ATTRIBUTE in your own widgets:
SLATE_TEXT_ATTRIBUTE was added as a stop-gap solution to allow all the code that was already passing text to Slate as an FString to continue to build without having to make any code changes.
In your own widgets, you should always use SLATE_ATTRIBUTE with the type FText, eg) SLATE_ATTRIBUTE(FText, Label)
This advice also applies to SLATE_TEXT_ARGUMENT.
2) Always pass text to Slate as FText (not FString):
I saw the following pattern a lot as I converting code over to use FText:
FString GetMyText()
{
return LOCTEXT("MyText", "My Text").ToString();
}
I fully understand how this happened in older code (as Slate only used to accept FString), however I still see it happening in new code. Slate has accepted both FString and FText for quite some time in order to allow the transition between these types to happen slowly, however that transition period has ended, and soon the FString support will be removed (likely by 4.10).
FText GetMyText()
{
return LOCTEXT("MyText", "My Text");
}
The above form allows some performance benefits as we can perform an optimised comparison on two FText instances to see if they match (as they are immutable so we only need to compare the pointers). When you pass Slate an FString, it internally marshals it to an FText, and as those instances can never have identical pointers, we always have to perform a full string compare to work out whether the source text has changed.
[HR][/HR]
So you may be wondering why this change was made, and the simple answer is localisation and live-culture changes.
FText is our localised text format, and user-facing text should typically either be localised (via LOCTEXT), or from some form of user or file based input (what FText calls culture invariant text), and by enforcing an API which only accepts FText, we force you to make a concious decision to not localise a piece of text (typically by calling FText::FromString).
This doesn’t just apply to text localisation, but numbers too! FText provides a suite of functions to format number types correctly for the current culture, making sure to use decimal and group separators appropriately, as well as respect any other quirks that a particular culture may have regarding their representations of percentages, currencies, or times.
More information about using FText can be found in the documentation, and Justin Sargent has previously written a blog post with some information about localisation in UE4.
Please let me know if you have any queries regarding this change.