1) There is a director blueprint condition property that is part of a condition container struct. The condition container is added as an external structure. Its director blueprint condition property has a customization that adds its payload variable properties.
2) The code in DetailLayoutBuilderImpl copies the properties from the external structure to the parent category. This includes both a) the director blueprint condition property, and b) the payload variables.
3) The newly added director blueprint condition property from #2 that got put in the parent category has its customization run again, and that customization again adds payload variables, meaning we have 2 copies of the payload variables added.
To fix this, in step 2, I check to see if the child nodes have an external root property node. If they do, I do not copy them to the parent category.
[REVIEW] [at]ue-sequencer, [at]juan.portillo
#jira UE-225007
#rb Juan.Portillo
[CL 36750381 by AdricEpic in 5.5 branch]
This is because when subcategories aren't supported, the code in FDetailLayoutBuilderImpl::GenerateDetailLayout() generates a detail layout and manually tries to copy the property nodes from generated child nodes to the parent category. However, custom rows will not have property nodes, and in this case the parent property that has been customized may not itself add a detail node.
The solution I have here which I'd like reviewed is in the case no PropertyNode is found for a child node, to look to the parent node and if the parent node has a valid property node, then add that instead to the parent category. This will force the same customization to run for the parent category. I considered trying to copy over the widgets from the custom property rows added, but this resulted in disconnected widgets.
I'm pretty sure the case I'm trying to solve for here is rare, and so far I haven't encountered any other property panes that even fall inside the if (!PropertyNode.IsValid()) case, but if there are ways to make this more robust, or if I need to take a different approach, please let me know.
Relevant slack thread: https://epicgames.slack.com/archives/C045H4DFN5P/p1724841764932099
[REVIEW] [at]editor-ui-systems
#rb Juan.Portillo, logan.buchy
[CL 36002471 by david bromberg in ue5-main branch]
* It wasn't possible to get at the IPropertyHandles for category-less properties since passing a "None" FName would default the category to "General". However, it is possible to construct struct/class metadata that has properties with no category.
* Allows detail panel customizations to be written that affect all properties.
#rb jordan.hoffmann
#jira UE-204966
[CL 31773963 by logan buchy in ue5-main branch]
- Added option to IDetailCategoryBuilder::HeaderContent() to let the content span the whole row (hides category label)
#rb karen.jirak
[CL 29125964 by mikko mononen in ue5-main branch]
The code in DetailLayoutBuilderImpl.cpp that is attempting to create a new category is relying on a value from a FProperty that is not necessarily initialized and should not be relied upon. Instead, use information from the UObject to initialize the Category and it's UProperty
#jira UE-196166
#rb JeanMichel.Dignard
[CL 28259427 by karen jirak in ue5-main branch]
~added isEmpty property to details categories for showing stub categories
~styling support to show them properly
#jira UE-195683
#rb ronald.koppers
[CL 28073151 by karen jirak in ue5-main branch]
There's a window after undo (between undo and next property view tick) where property nodes point to the previous data.
If e.g. a property customization needs to refresh cached data after undo, they will try to access the data via old pointers.
Similar issue happens when removing item from array, the tick of IDetailCustomNodeBuilder gets called before we have updates the property nodes.
All these issues happen because when we update the child nodes, there are some parts of code that still hold hard refereces to them, and they are not
actually cleared on FPropertyNode::DestroyTree(). That in turn will cause IPropertyHandle to be in valid state, but pointing to data that has been freed.
- Added bIsDestroyed on property nodes to be able distinguish property nodes which are still alive but destoyed
- Prevent calling Tick() on property tree nodes, whose property node is destroyed
- Changed Gameplay Tag, Tag Container and Query to poll for changes, because undo callbacks are triggered at times when the property handle (and underlying node) is pointing to old data
- The above gameplay tag & co change will also react to property changes from outside the details panel
#jira UE-188117 UE-190882
[CL 27705747 by mikko mononen in ue5-main branch]
- Fix properties under sub-categories not appearing at all when using Struct on Scope in Property Row Generator
#jira UE-182375
#rb karen.jirak
[CL 25953385 by Juan Portillo in ue5-main branch]
- Added IStructureProvider which allows to edit multiple instances of structs at a time
- Improved default value handling in standalone structure nodes
- Fixed bug where expanded nodes did not retain their expansion state when structure nodes were rebuild (e.g. when editing a component)
- Removed caching from Instanced struct customization
#jira UE-172047
#rb Jamie.Dale, Adrien.Logut
#preflight 644a48360f12404fb77173f6
[CL 25214019 by mikko mononen in ue5-main branch]
When property view widgets get reused, we are running (generate nodes) repeatedly while scrolling. Through some trial and error, I've identified that since I am only showing a fraction of the nodes I don't need to have all the nodes built; I can get away with generating the ones I will see, which improves performance from around 130 ms to 10-20ms per widget. I am adding a way to specify the properties you want to build and ignore the rest, which ultimately dramatically speeds up the PropertyView widget for the case where you are only showing a few properties from the object.
[REVIEW] [at]jay.Nakai, [at]sebastian.nordgren, [at]david.hamm
#rb sebastian.nordgren
#ROBOMERGE-OWNER: vlad.golovan
#ROBOMERGE-AUTHOR: vlad.golovan
#ROBOMERGE-SOURCE: CL 19036849 via CL 19036854 via CL 19038143 via CL 19038155 via CL 19039279
#ROBOMERGE-BOT: UE5 (Release-Engine-Staging -> Main) (v918-19018356)
[CL 19039995 by vlad golovan in ue5-main branch]
This represents UE4/Main @18073326, Release-5.0 @18081140 and Dev-PerfTest @18045971
[CL 18081471 by aurel cordonnier in ue5-release-engine-test branch]
