Some bindings fail in packaged builds (UE 5.4.3)
Hi there!
I've noticed that some of my properties are not being bound correctly (always the same properties) in packaged builds, even though editor builds seem to be completely fine. The data context is a UNoesisInstance and I set the XAML inside the constructor like so:
These properties hold valid initial values and I update them inside NativeConstruct:
I'm quite confounded as it is, and any help is very much appreciated :)
Editor (Development-Editor): Packaged (Development-Game): XAML snippet of a property that can't be bound in packaged builds:
I've noticed that some of my properties are not being bound correctly (always the same properties) in packaged builds, even though editor builds seem to be completely fine. The data context is a UNoesisInstance and I set the XAML inside the constructor like so:
Code: Select all
UOptionsMenu::UOptionsMenu() {
BaseXaml = LoadObject<UNoesisXaml>(nullptr, TEXT("/Path/To/My/XAML"));
Code: Select all
void UOptionsMenu::NativeConstruct() {
Super::NativeConstruct();
settings = UUserSettings::GetTotSettings();
brightness = settings->Brightness;
NoesisNotifyPropertyChanged(this, "brightness");
Editor (Development-Editor): Packaged (Development-Game): XAML snippet of a property that can't be bound in packaged builds:
Re: Some bindings fail in packaged builds (UE 5.4.3)
This was apparently due to FName shenanigans. I had to set WITH_CASE_PRESERVING_NAME for runtime/packaged builds to make it work. Though, I ultimately decided that I should probably follow UE's naming conventions to reduce the overall friction going forward.
Re: Some bindings fail in packaged builds (UE 5.4.3)
This was also discussed this here: viewtopic.php?p=16378
We don't recommend setting WITH_CASE_PRESERVING_NAME to 1, we discovered a few issues with this. Until we find a better solution (we could make changes to our Symbol implementation) we recommend following Unreal convention.
We don't recommend setting WITH_CASE_PRESERVING_NAME to 1, we discovered a few issues with this. Until we find a better solution (we could make changes to our Symbol implementation) we recommend following Unreal convention.
Who is online
Users browsing this forum: No registered users and 2 guests