EditInlineNew not working in editor

Branch: Binary build from the Unreal Launcher

Build version: 4.0.2-2034640+++depot+UE4-Releases+4.0

EditInlineNew/editinlinenew is not working in editor as there is no “new” button to create new instance of selected class.
I think that this issue could be connected with latest update as I am sure that some time ago that button was visible.

Repro Steps:
Action 1 Create new project
Action 2 Add new class:

UCLASS(editinlinenew, BlueprintType)
class UTest : public UObject
{
    GENERATED_UCLASS_BODY()
     
    UPROPERTY(EditAnywhere, BlueprintReadWrite, Category = "Properties")
    bool Enabled;
};

Action 3 Create new blueprint and add new field of type “object Test”

Action 4 Save blueprint

Action 5 Set default value for created field

Hi cloud,

According the comment with CLASS_EditInlineNew (the flag that the class gets marked with if EditInlineNew was specified) there should be new button. I can’t speak for how it used to be, but that definitely appears to be how it should work.

I’ll bring it up with the appropriate people here, and log a bug so it doesn’t get lost in the mix. Thanks for bringing it to our attention!

So with more investigation, it seems that this has been purposely disabled for blueprints. There was an issue where duplicating a blueprint instance would not re-instance the EditInlineNew property.

However, recently it seems that the bug that was causing this has been fixed. So we can now fix this issue up. I’ll log the issue for us to fixup (so that we don’t forget about it).

I’m glad you brought this up so we can address it, now that we’re able to. Thanks!

Thank you very much guys! :smiley:

I spoke with RCL on #unrealengine and it seems someone has been assigned to this bug, but it’s unlikely they will tend to it in the near future due to other tickets being higher priority.

This is something that is preventing me from continuing my work, so I have taken it upon myself to see if I can fix this and submit a pull request.

Thanks

Thanks for letting me know. I hope this problem will be solved as this is something that is stopping me too.

Bit of an update here.

After some investigation into the destructor of FPostConstructInitializeProperties it turns out that when objects are “initialized” they are only “instanced” (meaning deep copies of members are made) if they contain subobjects, and only deep copies of said subojects are made. Everything else reverts to the default values defined in the “default object” which is a completely unmodified instance of the class at hand.

If what I just said is true, then the bug itself is actually missing functionality, and this code was never intended to create instances of non-TSubobjectPtr properties. I believe FObjectInstancingGraph is the mechanism through which subobjects are currently “deep copied,” and likely where this functionality belongs.

Update #2:

I guess ‘suboject’ refers to any UPROPERTY that is a UObject*. Or at least that is the way it appears now. FObjectInstancingGraph::InstancePropertyValue() does in fact check for the DefaultToInstanced flag on the class, but for some reason it still doesn’t create a copy of it.

Update #3:

So evidently objects are only “instanced” in the way we are wanting if they manage to make it into the ComponentInts array inside an object’s PCIP, which requires that you go through PCIP.CreateDefaultSubobject() to achieve that. This causes the destructor of the PCIP to instance the subobjects appropriately.

One thing I am thinking about doing is manually adding UObject properties marked as Instanced (or classes that are marked as DefaultToInstanced) to the ComponentInits list so that they will be initialized properly. I like this approach as it seems to be the least likely to cause problems down the road. PCIP’s are only instanced for the duration of the constructor, and as far as I can tell they don’t actually care if non-TSubobjectPtrs are in that array. This would require traversing the properties of a UClass from within the constructor of FPostConstructInitializeProperties and adding them to that array. We can’t really go through the current subobject system in PCIP because that requires the objects be uniquely named on line 2412 of Class.h.

Update #4: So that doesn’t work because in the destructor of the PCIP we’re actually copying values from the default class object (despite what the comments say), which of course doesn’t result in a deep copy of the object we are actually duplicating, but a deep copy of the default class object. At some point after this those values are copied over from the object you are duplicating (otherwise duplicating wouldn’t work!) So I’ll continue to try and look where that happens.

Update #5: I think this is more of a case of missing functionality and not a “bug” in the typical sense. That is, this code has yet to be written and it’s probably not just handful of lines that need to be changed to fix this. There is more than spot that this code could go, but only one spot that wouldn’t seem extremely hacky and gross to the people who wrote the original code.

I’m going to make an effort to personally reach out to the engineer currently assigned to the ticket to see what he says. If I can’t get any official help on this, then I think our best bet will be to wait for a fix and design around this limitation.

It sucks because this feature is rather powerful. The sooner it gets fixed the better.

One more time thank you for your commitment to a cause :D.

First off, thavlik, awesome dedication and thank you so much for digging into this like you have. The feature request was sitting in our backlog, but I’ve just bumped its priority so that hopefully someone gets to it sooner. Whoever grabs it, I’ll point them here so that they can benefit from all the hard work that you’ve already done.

Thanks guys for the encouragement :slight_smile: and I’m happy to hear that the priority on this got bumped up. Thanks again for that, Mr. Beach.

Hi,

May I check if this issue has been fixed? If there is a TTP that would be great too.

Regards,
Ding

It seems that this issue is still not fixed.

The TTP for this was #333611, and was fixed back in September (with CL 2280605).

I think the piece you may be missing is tagging the property/variable “Instanced”. “EditInlineNew” more or less says “this class can be instanced”. You can prevent sub-classes from being instanced by tagging them with “NotEditInlineNew”.

There’s a bug it seems, where variables of a EditInlineNew class show up in the defaults, even when the variable/property is not marked “Instanced”.

To get the behavior that you expect, you can mark the property like so:
UPROPERTY(EditAnywhere, Instanced, BlueprintReadOnly)
UTest* MyUTestVar;

Once the variable is marked “Instanced”, you won’t see a button, but a dropdown where you can pick the class type for it to instantiate. If you pick a class, all its defaults will then be exposed for you to set.

Unfortunately, you cannot mark Blueprint created variables as “Instanced”. I’ve created a bug to allow this (UE-6959, for reference).

Yes, it’s working with Instanced. Thank you so much for fixing this :smiley:

“EditInlineNew” Indicates that Objects of this class can be created from the Unreal Editor Property window, as opposed to being referenced from an existing Asset. The default behavior is that only references to existing Objects may be assigned through the Property window). This Specifier is propagated to all child classes; child classes can override this with the “NotEditInlineNew” Specifier.

Hi,

has the bug UE-6959 ever been resolved? It seems it is still not possible to mark Blueprint variables as “Instanced”.

We hope this Blueprint Class “EditInlinenNew” plugin (which no longer requires any C++ to use the EditInlinenNew feature) will help you.
https://www.unrealengine.com/marketplace/en-US/product/blueprint-editinlinenew