TSet not supported for TitleProperty meta data property specifier

Hello!

As the title implies, I was wondering why TSets don’t support the TitleProperty meta specifier. After some digging, I’ve found how maps and arrays are handled via SPropertyEditorArrayItem. Specifically, Maps and Arrays pass the support check and thus construct a SPropertyEditorArrayItem for the entries. However, TSet defaults to SPropertyEditor.

I’ve been able to get it working by adding a new SPropertyEditorSetItem that is a copy of SPropertyEditorArrayItem apart from changing the ::Supports function to check if the owning property is a FSetProperty.

This seems to work fine and displays the title property as you’d expect. However, this made me question a couple things.

  1. Why weren’t TSets supported if this change was so simple. Am I missing something crucial with sets that shouldn’t allow this behaviour? Or is it a case of the team just hadn’t gotten around to adding it?
  2. If it’s that it just hasn’t been addressed and this is a viable solution, is a simpler solution to instead check in SPropertyEditorArrayItem::Supports if the owning property is a FSetProperty and return true in that case as well?

Any information you have on this would be helpful!

Kind regards,

Darien

[Attachment Removed]

Steps to Reproduce

  • Create a test struct on a basic actor class
  • Ensure there is a UProperty of time String and call it “TestName”
  • Add a TSet UProperty, use the test struct as the type, and add the TitleProperty meta specifier
  • Set the specifier to be the “TestName” variable
  • Observe the TSet entries don’t reflect the struct TestName value
    [Attachment Removed]

Hi,

This is almost certainly an oversight, as I believe TSet support in detail panels was added a bit later than the others if I’m recalling correctly. It seems like we should be safe to just expand SPropertyEditorArrayItem::Supports to cover the TSet case as well; I’ll get that change checked in and let you know once I have a CL available.

[Attachment Removed]

Hi,

This should be checked in now at CL#54335535. Thanks for the report!

[Attachment Removed]