In the level editor, when configuring a component that is part of an actor blueprint, adding entries to a TMap with C++ enum keys results in duplicate keys and an incorrect warning popup.

Note: This started happening in UE 5.4 and persists up to latest. It is probably related to [Link Removed] Closed ([Link Removed]) and its fix CL 35178509.

Consider a TMap property with C++ Enum Keys. When adding new items using UE's property editors, each new items is expected to come automatically with the first unused enumerator value until all options have been used. However, if the TMap is inside a component that is part of an actor blueprint, adding items to it in an actor instance in the Level Editor does not behave correctly. Each new attempt to add an item produces a warning popup "Cannot add a new element to the tmap as all the enum values are already added" (even for the very first item). Moreover, all items initially come with the first Enum entry (not the first unused one), resulting in several items with duplicate keys.

A preliminary investigation seemed to track the problem to this call chain when adding the first item to a map:

FPropertyEditor::OnAddItem()
FPropertyHandleMap::AddItem()
FPropertyHandleMap::AddItemWithKey()
FPropertyValueImpl::AddChild()
FPropertyNode::RebuildChildren()
FItemPropertyNode::InitChildNodes()
FPropertyNode::GetReadAddress()
FPropertyNode::GetReadAddressUncached()
FPropertyNode::GetReadAddressUncached()
FObjectPropertyNode::GetReadAddressUncached()

{ const FProperty* InItemProperty = InNode.GetProperty(); UStruct* OwnerStruct = InItemProperty->GetOwnerStruct(); if (!OwnerStruct || OwnerStruct->IsStructTrashed()) return false; //(...) }

It appears that, for some reason, the "return false" above gets hit, leading to FPropertyNode::GetReadAddress() returning null and FPropertyNode::RebuildChildren() silently failing. As a result, inside FPropertyHandleMap::AddItemWithKey(), FPropertyValueImpl::AddChild() returns the correct new index 0, but FPropertyValueImpl::GetChildNode(0) does not return a valid child.

1. Create and edit a new Blueprint "TestComponent" based on ActorComponent
1.1. Add a variable "MapOnComponent"
1.1.1. Make it a TMap with keys of type "AnimPhysSimType" (or any other C++ enum)
1.1.2. Make it instance-editable (eye icon)
1.2. Compile the BP
1.3. Verify values are correctly added to the default value of "MapOnComponent"
1.4. Clear "MapOnComponent", compile, save and close the BP

2. Create and edit a new Blueprint "TestActor" based on Actor
2.1. Repeat steps 1.1 to 1.3 but with a variable "MapOnActor"
2.2. Add a component of type "TestComponent"
2.3. Compile and repeat test 1.3 for variable "MapOnComponent" inside the added component
2.4. Make sure all test TMaps are empty. Compile, save, close all BPs.

3. Place an instance of "TestActor" on any level
4. Verify the behavior of adding entries to each test variable:
4.1. "TestActor.MapOnActor" - correct
4.2. "TestActor.TestComponent.MapOnComponent" - incorrect!

The incorrect behavior is that, on each attempt to add an entry to the tmap:

• Warning "Cannot add a new element to the tmap as all the enum values are already added" pops up
• An entry with the first enum value is added, resulting in several entries with duplicate keys

Notes:

• Does not repro with TMap variables defined in CPP or BP actors (only in CPP or BP components)
• Does not repro when TMap entries are added in the blueprint editor (only for instances in the level editor)
• Does not repro when the component itself is added directly to an actor in the level editor (only for components added to blueprint actors)
• The behavior above is for Enums defined in C++ (e.g. AnimPhysSimSpaceType). For user-defined BP enums (e.g. BrushBlendType), the behavior is different (although also non-ideal): New entries are always created with the first enum value (not the first unused one), and when it already exists in the map, an error "Cannot add a new key to the map while a key with the same value exists" pops up.