Array Editting Workflow (particularly with interfaces)

[anonymous_user_10b2fd67]

Hey All,

I have an array of interface pointers that, ideally, I’d like the Editor to manage, instantiate, and edit the properties of those children classes.

Something like the following:

Currently I can’t expose the raw Interface pointer, it has to go through the TScriptInterface (which just seems to bind an interface to an uobject, not sure what happens if those are one and the same object), but I don’t see a way to instantiate a class inline within the current array property widget.

I suppose I could just create these interfaces as normal UObjects and have them referenced, but that adds a level of indirection for users to get to the values they would want to tweak.

Any thoughts or suggestions?

[kamrann]

So to clarify, you have a property in your class of type TArray< TScriptInterface< ISomeInterface > > and in the editor details panel, you want to be able to add new items to that array of any class which implements ISomeInterface, and edit the properties of those items?

it has to go through the TScriptInterface (which just seems to bind an interface to an uobject, not sure what happens if those are one and the same object)

C++ interfaces are implemented through multiple inheritance. I think this class just deals with offsetting the address of the interface with respect to the base object.

UE4 interface support is still rather limited. Unfortunately despite heaps of interface related questions being posted, Epic still haven’t updated the docs properly or given a run down on what the limitations are. The most flexible approach I’ve found is to just use a raw UObject pointer and handle checking for interface support myself. This circumvents the issue of TScriptInterface/interface pointers not working at all with classes that have the interface added to them in blueprint rather than C++. This could be made to work in your case, but it’d require a bit of work to make it easy to use in the editor.

If you change your property to an array of UObject* and add the Instanced property specifier, and add the EditInlineNew specifier to each of the classes which implement the interface, you’ll be able to instantiate them in place. Unfortunately your drop down list will include a million other classes too. You’d have to create a details customisation to filter out everything that isn’t a class and doesn’t implement your interface.

This last part is similar to something I’ve been attempting myself, so I might be able to adapt it to your case if you’re interested.

[anonymous_user_10b2fd67]

@kamrann;353807

So to clarify, you have a property in your class of type TArray< TScriptInterface< ISomeInterface > > and in the editor details panel, you want to be able to add new items to that array of any class which implements ISomeInterface, and edit the properties of those items?

Correct.

C++ interfaces are implemented through multiple inheritance. I think this class just deals with offsetting the address of the interface with respect to the base object.

UE4 interface support is still rather limited. Unfortunately despite heaps of interface related questions being posted, Epic still haven’t updated the docs properly or given a run down on what the limitations are. The most flexible approach I’ve found is to just use a raw UObject pointer and handle checking for interface support myself. This circumvents the issue of TScriptInterface/interface pointers not working at all with classes that have the interface added to them in blueprint rather than C++. This could be made to work in your case, but it’d require a bit of work to make it easy to use in the editor.

If you change your property to an array of UObject* and add the Instanced property specifier, and add the EditInlineNew specifier to each of the classes which implement the interface, you’ll be able to instantiate them in place. Unfortunately your drop down list will include a million other classes too. You’d have to create a details customisation to filter out everything that isn’t a class and doesn’t implement your interface.

This last part is similar to something I’ve been attempting myself, so I might be able to adapt it to your case if you’re interested.

The raw UObject approach is a good idea (albeit you have to do the interface compatibility check yourself as you mention). Let me explore down that route a bit. Thanks for the feedback/suggestion. I agree that I’d love to see Interfaces documented and expanded a bit more.