How to load a UMG widget from BP address in C++?

Development World Creation
, , , ,
1

At the moment I’m trying static load object;

URRUserWidget* ButtonBlueprint = Cast<URRUserWidget>(StaticLoadObject(URRUserWidget::StaticClass(), NULL, *Address));

This doesn’t work. Static constructerhelper functions wouldn’t be a good way to do it, because this can’t be in a constructor.

Does anyone know how to do this?

EDIT:

It looks as if the way to do it would be to make a UObjectLibrary and load it with the blueprint data using the paths. However, for some reason the data won’t load into the object library. This is what I’ve done to load it;

TArray<FString> WidgetPaths;

if (QuestionFile.ParseIntoArray(&WidgetPaths, TEXT("%"), true) > 0)
{
		Questions = UObjectLibrary::CreateLibrary(URRUserWidget::StaticClass(), true, true);
		Questions->AddToRoot();
		Questions->LoadBlueprintAssetDataFromPaths(WidgetPaths);
		int32 AssetCount = Questions->GetAssetDataCount();
		UE_LOG(RRQuery, Warning, TEXT("Assets loaded in the Questions Library: %d"), AssetCount);
}

The log is showing that its always empty…

EDIT:

Progress!

I ditched the UObjectLibrary idea as I couldnt get it to read in to the library. And went back to using static load but also using FStringAssetReference and ResolveObject;

FStringAssetReference Widget = (*Address);
	StaticLoadObject(UObject::StaticClass(), NULL, *Widget.ToString());
	UObject* Resolved = Widget.ResolveObject();

	UBlueprint* WidgetBP = Cast<UBlueprint>(Resolved);

	if (WidgetBP->GeneratedClass->IsChildOf(URRUserWidget::StaticClass()))
	{
		return *(WidgetBP->GeneratedClass);
	}

	else return NULL;

However, it breaks on the return. All the data looks right, but it breaks to “return OwningGameInstance” in world.h. My owning game instance appears to be NULL. What this has to do with the price of tomatoes, I have no idea…

2

Hey Rama

Thanks for the reply! My design is very data-fed. So events are being triggered by queries to arrays that are loaded from data tables. Hence the desire to use BP addresses. But, lets say that the excel spreadsheet had the name of a BlueprintImplementableEvent in it;

Would I have to have a unique BlueprintImplementableEvent for every UMG widget? I’m unclear as to how I would read off a string from the spreadsheet, and use that, without having an insane number of events… Probably I havent properly understood what you’re saying.

3

I think if I can cast to UWidgetBlueprint rather than Blueprint, then the generated class would be the right one. This must be whats causing the error. Casting from the UObject doesnt work. Do you think there’s a way to get a UWidgetBlueprint from there?

I’ve tried to cast from both UObject and UBlueprint and neither works, which is odd, because UWidgetBlueprint inherits from both…

4

I can highly recommend you just send a BP event from C++ telling Blueprints you want a certain UMG menu activated.

I’ve just finished implementing a file browser and a custom search feature for game-specific data, all visuals done in UMG, all inner work done in C++

BP implementable event is your friend for this!

Think of it like this, you are sending a request from C++ to BP, asking BP to do something and for UMG, BP is the best place to be.

But UMG can turn around and call C++ functions to get all the inner work done!

UFUNCTION(BlueprintImplementableEvent, Category="Part Colors", meta=(FriendlyName = "Joy Mech ~ CPP Request ~ Open Part Colors"))
virtual void CPPRequest_OpenPartColors();

Part Colors is a UMG widget that I want to open from C++

I simply call that event anywhere in code
this->CPPRequest_OpenPartColors(); //this = my syntax to know it is a BP Impl event

Then in BP I actually implement it, and C++ is free of trying to manipulate UMG directly, but having ability to direct it.

I am currently writing a book on UE4 C++ where I will explain this in greater detail.

Rama

5

I cant see why your static load object is not working but it also is far from ideal method in my opinion, given that packaging can sometimes mess up the paths you see in the editor, so hardcoding them is just not a good idea!

Why do you feel you need so many different user widgets that you have to look them up by address?

If you just make a generic user widget with a scroll box, then you can use AddChild on the scroll box (make sure it is a variable),

to fill it with arbitrary data

the child element of the scroll box can itself be a user widget, that has its own BP code and performs different actions via click events or whatever you want

#Example For You

I have a good example of this usage in my free project for Rebindable Keys

[Full Project] Rama's UMG Rebindable Key System, Rebind keys at Runtime! - Programming & Scripting - Unreal Engine Forums!

Everything, the name label, the input field ,and the check boxes are a single widget which is created many times over and put into the scroll box, its data changed each time.

The data itself is the actual contents of Project->Input

As you see in video my widget is updating itself to the new contents of Project->Input after I add new entries

The data is stored in config file, but my UMG auto updates itself.

Since your system is so data driven you should abstract your UMG so it can accommodate your data needs in a multi-purpose way.

Again I have full example of this in my sample project!

[Full Project] Rama's UMG Rebindable Key System, Rebind keys at Runtime! - Programming & Scripting - Unreal Engine Forums!

It requires a bit of fancy UMG coding but you can make it so your core data, whether its on a server somewhere or is binary data, can be automatically reflected properly by your UMG using a single set of generic UMG widgets

-Rama

6

Hey Rama

That sounds like the ideal solution. The reason why I thought I needed multiple UMG widgets is because clicking on the text fires various delegates. It’s part of a dynamic dialogue system- where characters are not nailed to the floor, they respond and the system updates animation, audio, behavior tree blackboards etc. When the player has a chance to respond, a UMG widget is created and the player makes a choice. Clicking on the text can load new streaming levels etc. So the widgets are quite different in their effect.

I’ll accept your answer but before I do, what you were saying about packaging and paths makes my hair stand on end! :slight_smile:
So what you’re saying is that pure data- such as KV pairs, loaded by the Data Tables, is fine- but any assets dynamically loaded as a result of queries should be handled using Object Libraries etc? I mean, if the paths to the data tables were to get messed up, the system wouldn’t work. Thinking about it, I’m loading the data tables when streaming levels are loaded- would it be better to make each data table a variable in the BP of the streaming level?

Thanks!