is there a way to force the Customization class to redraw?
In the CustomizeChildren() function I decide to draw only specific elements of my UStruct, dependend on another value in the struct (so UI gets cleaned up for properties which anyway won’t be used).
if (ValueIsAllowed(type, propertyName, &customPropName) == true)
{
IDetailPropertyRow &row = StructBuilder.AddChildProperty(ChildHandle.ToSharedRef());
if (customPropName != "None")
row.DisplayName(FText::FromName(customPropName));
}
Custom function:
void FStructCustomization::OnValueChanged()
{
//force struct to update, so CustomizeChildren gets called again.???????
}
If the first of the properties get changed, I want that CustomizeChildren() gets called again, so the layout will be updated to the new visible values.
I guess this should not be impossible?
If yes, is there another way to update all content?
Assign the result of CustomizationUtils.GetPropertyUtilities() to a member variable of your customization class.
Then in OnValueChanged, called RequestRefresh() on that pointer. Pretty sure that should do it.
An alternative approach is to just use delegates to provide dynamic visibility for different parts of your customization, so you don’t need to rebuild. That can get messy if you have a complex customization though.
Yeah.
OnValueChanged breakpoint is triggered. And after that no CustomizeHeader or CustomizeChildren breakpoint is triggered.
Yes in fact, I’m referencing a content browser asset in the Type variable. And when I change this asset pointer (by dragging or selecting from the dropdown) OnValueChanged is called.
I can’t see anything wrong with your code, and calling SetValue should not make any difference.
I assume you’re entering a new value for the ‘Type’ field of your struct and hitting return, and the label doesn’t update? Have you debugged and checked that, for example, OnValueChanged is being called.?
In that case I’m afraid I’m out of ideas, looks like it should work. I can only suggest trying to simplify your customization and seeing if you can get RequestRefresh to work at all, then if so work backwards to see why it doesn’t work in this case.
as I debugged through all the ue4 code, I finally realized that customizeHeader and customizeChildren are only getting called on initialization anyway. So there can’t exist a way for a simple IPropertyCustomization to get these functions called again.
Although I found the class GameplayEffectModifierMagnitudeDetails.cpp in which delegate functions are used for visibility!