FClassFinder vs StaticLoadClass

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.