C++ created UMG widget don't display on Standalone Play.

[creasso]

Greetings.

I got a way to create an UMG widget from code:

//On my HUD class I have a pointer to a widget: UMyWidgetClass * MyWidgetPointer:

void AMyHUD::AddUMGWidgetToScreen()
{
	if (UMyWidgetClass == nullptr)
	{
		UClass * MyWidgetLoadedClass; // Creates a class
		FString WidgetBPAddress = "/Game/Somedir/Somedir/WIDGETBP.WIDGETBP";
		UBlueprint * WidgetBP;
		WidgetBP = Cast<UBlueprint>(StaticLoadObject(UBlueprint::StaticClass(), NULL, *WidgetBPAddress, NULL, LOAD_None, NULL));
		check(WidgetBP)
		{
			MyWidgetLoadedClass = WidgetBP->GeneratedClass;
			
                        MyWidgetPointer = CreateWidget<UMyWidgetClass>(GetWorld()->GetFirstPlayerController(), MyWidgetClass);
			MyWidgetPointer->AddToViewport();
		}
	}	
}

Additional Info:

This method just works on PIE and with an offset from mouse coordinates (this widget should store a custom mouse cursor).
On Standalone launchs the widget doesn't show at all, I've checked the Player0 Viewport Size and it's zeroed XY.
I'm calling the method from AGameMode::StartPlay(), what I thought is the same as make the creation and call from the Game Blueprint.

Thoughts? Tips?

[creasso]

Found the trouble/bug that is causing the viewport size to collapse:

Hidden Widget Bug

Now just need a way to compensate the offset movement on PIE.

[creasso]

Mouse Position answered here: Nick's tip On my way now!

[ruohki]

sometimes it helps to cook the content

[NickDarnell]

Reposting here in case others see this.

Don't load a widget class/asset in that manner. The same goes for anything blueprint based, the blueprints are an editor time only concept, that's why the WidgetBlueprint class is in an editor module - the UBlueprint will likely be soon as well. You should expose a TSubclassOf<UUserWidget> UProperty on your HUD, set the value in the editor, and it will be the class you want in native code. No need to muck around with hardcoded paths and loading blueprint assets.

[cmartel]

Reposting here in case others see this.

Don't load a widget class/asset in that manner. The same goes for anything blueprint based, the blueprints are an editor time only concept, that's why the WidgetBlueprint class is in an editor module - the UBlueprint will likely be soon as well. You should expose a TSubclassOf<UUserWidget> UProperty on your HUD, set the value in the editor, and it will be the class you want in native code. No need to muck around with hardcoded paths and loading blueprint assets.

As an example, here's the barebones of how we load our HUD asset in our game:

	/** HUD UMG widget class. */
	UPROPERTY( Category=Widgets, EditDefaultsOnly )
	TSubclassOf<UUserWidget> HUDWidgetClass;

	/** HUD UMG widget instance. */
	UPROPERTY()
	UMyHUDWidget* HUDWidgetInstance;

void AMyHUD::PostInitializeComponents()
{
	Super::PostInitializeComponents();
	HUDWidgetInstance = CreateWidget<UMyHUDWidget>( PCOwner, HUDWidgetClass );
	check( HUDWidgetInstance != nullptr );
}

[creasso]

Question:

Where do you access this property after?
A - Level BP, getting a reference to the HUD.
B - Some project Settings on the editor TAB.

If A, it's all I'm trying to avoid.

[creasso]

Great... Just now I've seen the "+" button at side from the Default GameMode Classes to create "NonActor" ClassBlueprints.
Other than UMG elements and the Level BP I thought that all Blueprints would just be used as the U3 Archetypes, meaning, things that need be placed on levels.
Summed with what Nick told me on Answerhub my tools pallete grew considerably now (too much options I'll probably get lost LOL).

PS: @cmartel Now I understood what you said, I apologize if I was a bit stupid.