FClassFinder vs StaticLoadClass
On this page
FClassFinder
uses compile-time checking. If the asset path is incorrect, you’ll get a warning during compilation. It also encapsulates the logic of loading and checking the asset, reducing the amount of code you need to write.
FClassFinder example
// MyPlayerController.cpp
#include "MyPlayerController.h"
#include "UObject/ConstructorHelpers.h"
#include "Blueprint/UserWidget.h"
// Constructor
AMyPlayerController::AMyPlayerController()
{
// Initialize Inventory screen widget
static ConstructorHelpers::FClassFinder<UUserWidget> InventoryWidgetClass(TEXT("/Game/UI/W_InventoryScreen.W_InventoryScreen_C"));
if (InventoryWidgetClass.Succeeded())
{
InventoryScreenWidgetClass = InventoryWidgetClass.Class;
}
else
{
UE_LOG(LogMyPlayerController, Error, TEXT("Could not find the Blueprint class for the inventory widget!"));
}
}
StaticLoadClass
on the other hand can be used outside of constructors and in more dynamic contexts, like runtime loading based on user input or configuration files. This gives you more direct control over the asset loading process, which can be useful in interesting scenarios like conditionally loaded assets.
StaticLoadClass example
// MyPlayerController.cpp
#include "MyPlayerController.h"
#include "UObject/UObjectGlobals.h"
#include "Blueprint/UserWidget.h"
// Constructor
AMyPlayerController::AMyPlayerController()
{
// Initialize Inventory screen widget
InventoryScreenWidgetClass = StaticLoadClass(UUserWidget::StaticClass(), nullptr, TEXT("WidgetBlueprint'/Game/UI/W_InventoryScreen.W_InventoryScreen_C'"));
if (!InventoryScreenWidgetClass)
{
UE_LOG(LogMyPlayerController, Error, TEXT("Could not find the Blueprint class for the inventory widget!"));
}
}
Use FClassFinder
if you prefer compile-time checking, simplicity, and readability, especially when loading classes in constructors.
Use StaticLoadClass
if you need more flexibility for runtime or dynamic loading scenarios.