For USTRUCTs, you need to derive from IPropertyTypeCustomization and use RegisterCustomPropertyTypeLayout. RegisterCustomClassLayout is for UCLASSs only. This is covered in the guide you linked.
The correct place to register customizations is in the startup function of an editor module. There’s a tutorial here, not sure if it’s fully up to date.
I’ve never tried to register a customization for a struct used in a data table, but I guess it will probably work if you fix the above issues. I wrote a tutorial on customization here which may interest you, but it doesn’t cover struct customization so is probably of no use in this particular case.
Yep you can do that using IPropertyTypeCustomization. For the enum selection, you can register a visibility delegate to each dependent property, that checks the current value of your MsgType property to determine if other properties should be visible or hidden.
As for array customization, I have a feeling that has it’s own customization interface, but I’ve not tried to do it. One thing that can help reduce the indentation is to add Meta=(ShowOnlyInnerProperties) to any struct property declaration. Pretty sure it works with properties that are an array of structs too, though I’m not totally sure if it plays nice when customizations are registered for the struct.
Okay so no matter what I do, I still can’t get it to affect anything, despite hours and hours of trying different things, google searches, etc.
I’ve got the module in and working (displays a Log at startup)
I’ve created a class that extends IPropertyTypeCustomization, with the name FDMsgCustomization (Struct name + Cusomization).
100% of the ‘CustomizeHeader(…)’ code shown in the guide causes errors, so instead I just put a log to see if it’s actually executing.
I then implemented it in my KnightsQuestEditor module’s cpp like so:
Ah, I noticed this previously but forgot to mention it - you need to drop the prefix letter from the type when you identify it by string. So pass “DMsg” as the first argument to RegisterCustomPropertyTypeLayout. Likewise drop the ‘U’ or ‘A’ any time you identify a UObject/AActor-derived class by name.
And no, generally your type will be in a header inside your game/runtime module, but your customization class should be in your editor module. Also, the name of the customization class is irrelevant. I think if you adjust the string as above, you’ll be good to go.
One thing that could help is always look at editor code, search for references of
IPropertyTypeCustomization
or if you are using something like VAX (which I highly encourage to do) you can locate that interface class middle mouse click on it and it should list derived classes. From there you can explore how each class handles things and learn things that won’t be mentioned in documentation for quite some time. I must say Epic improved docs a lot (I was whining a lot about it) since I started using UE couple years ago but on this front there is still a LOT to improve. .)