Download

Use FObjectFinder with TSubClassof variable?

Is it possible to use the TSubclassof container with FObjectFinder? I basically want to set the default property of a TSubclassof<UUserWidget> The following doesn’t compile:



	static ConstructorHelpers::FObjectFinder<UUserWidget*> ErrWdgtCntnt(TEXT("WidgetBlueprint'/Game/UI/Widgets/Common/WGT_Warning.WGT_Warning'"));
	if (ErrWdgtCntnt.Object != nullptr) { ErrorDialogWidget = (ErrWdgtCntnt.Object); }


You shouldn’t have a * on the end of your FObjectFinder template argument. Otherwise should work fine.

Edit: actually there’s an instance/class issue here, need to think a bit more…

So basically what you’re doing there (if you remove the *) is looking for an actual asset of type UUserWidget. Those don’t exist, you have a widget blueprint asset, which has an associated class which is what you’re after. I don’t have time to test it out now, but something like this might do it:


static ConstructorHelpers::FObjectFinder<UWidgetBlueprint> ErrWdgtCntnt(TEXT("WidgetBlueprint'/Game/UI/Widgets/Common/WGT_Warning.WGT_Warning'"));
if (ErrWdgtCntnt.Object != nullptr)
{
  ErrorDialogWidget = ErrWdgtCntnt.Object->GeneratedClass;
}

Yeah my fault, I ended up using UClass instead which seemed to work, though I feel like I should be casting it that way…

Also had to add _C to the reference… for some reason. I’ll try your version… that’d make more sense. Thanks!

When I tried to use UMG in C++ I could make it work loading its class inside constructor this way:


static ConstructorHelpers::FObjectFinder<UClass> ErrWdgtCntnt(TEXT("/Game/UI/Widgets/Common/WGT_Warning.WGT_Warning_C"));
ErrorDialogWidget = ErrWdgtCntnt.Object;

and this way outside constructor:


ErrorDialogWidget = StaticLoadClass(UObject::StaticClass(), nullptr, TEXT("/Game/UI/Widgets/Common/WGT_Warning.WGT_Warning_C"));
UUserWidget * HUD = CreateWidget<UUserWidget>(GetWorld(), ErrorDialogWidget);

Cheers

Yeah, searching directly for the UClass like that will work. The only drawback is that you’re then relying on the assumption that the name of a blueprint generated class is the same as the name of the blueprint asset with “_C” appended. It’s unlikely Epic would change this, but it’s not guaranteed. There’s also the (again very unlikely) possibility that this might fail in the case of a naming conflict.