I have read several links regarding creation of widgets in C++. One of them is this:
Unfortunately that was in 2014. It’s 2 years from then. So I assume, UE is much better and support many more libraries. So with UI 4.12.5, is it really possible to fully create a simple widget with a simple
UTextBlock in it and display a text on screen?
Remember, my question is to do that in pure C++. No blueprint widget or any reference to blueprint widget is allowed in here. If you can answer it, please provide the very simple source code in header file and cpp file to enable this. Because I’ve encountered many people who give unclear answers (without source code) which cannot be compiled or does not solve the problem.
First you create a widget that extends UUserWidget.
class UMyUserWidget : public UUserWidget
Next you override the NativeConstruct method.
virtual void NativeConstruct() override;
In your .cpp file you implement NativeConstruct.
// Bind delegates here.
In your PlayerController class create and display the widget.
UserInterface = CreateWidget<UMyUserWidget>(this, UMyUserWidget::StaticClass());
UserInterface->AddToViewport(9999); // Z-order, this just makes it render on the very top.
Now that you have created your base widget in C++ you can start adding components to it. It is extremely important to note that widget components are also widgets. This means you create them in the exact same way you create your UUserWidget.
In your header file define a widget type. In this case I’ll define a UButton.
In your CPP file you will instantiate that button.
UPanelWidget* RootWidget = Cast<UPanelWidget>(GetRootWidget());
ExampleButton = WidgetTree->ConstructWidget<UButton>(UButton::StaticClass(), TEXT("MyButtonName")); // The second parameter is the name and is optional.
ExampleButton->OnClicked.AddDynamic(this, &MyUserWidget::OnButtonClicked); // Example click binding.
There are, of course, more steps in this like setting the padding, color, and other properties. It is best that you give your widgets names so you can find them later using using WidgetTree->FindWidget(TEXT(“WIDGET_NAME”)).
I don’t understand why you repost the same thing that failed to work?
You admitted yourself that you never tried this, so why bother answering it?
Why did you create a new question for something you already asked?
The content above works. Just because you can’t quite figure it out doesn’t mean it doesn’t work. You are fishing for a different answer when one was provided for you. Spend the time you spent making this question reading the documentation I linked above. You are programming C++. We expect a certain level of competence and a desire to learn. We are not here to do your homework for you.
To add insult to your wound the code I posted works. You’ll notice, however, that the button does not appear in the hierarchy in the left panel.
- First, you did not read the question correctly.
- Second, you gave irrelevant answer (I asked for
UButton ! )
- Third, you intentionally gave incomplete answer (so people will be confused)
- You have clearly proved that you used a widget blueprint reference and NOT pure C++
- Your solution still fail, because the value from
GetRootWidget() is always
- You have an arrogant attitude
- You mock me and accused me of being incompetent
Man, what is your problem ??!!
Do you love to proclaim that you’re the best and underestimate people??
If your answer was satisfactory in another post, I would have not post this new topic! It was slightly a different topic anyway.
Do you even have eyes to clearly see that your answer does NOT work??
Here’s 4 simple files to simulate your answer and to prove that you’re wrong!
You must understand that people asking for answers are NOT expert people. We are all trying to learn new things and trying to help each other here. And for sure that intentionally giving false answers or incomplete solutions or solutions that do not work, is an act of diminishing the spirit of this UE community!
If the documentations from UE is verbose, like Java programming language, then it will greatly help me and many developers here. Due to lack of information in the docs and lack of official tutorial from UE team, people ask questions in this community.
Sorry if I’m rude, but you crossed the line first man!
I admit I left out the RebuildWidget section, and that is my bad. Also worth noting is all I did was extend the class in UMG and used TSubclassOf for the class in my PlayerController. I did absolutely NOTHING in the UMG class in regards to events. All I did was drag and drop a button and 2 progress bars that are not even hooked up to anything.
With that said, you are flipping your lid because I gave an example with UButton instead of UTextBlock? You also seem extraordinarily against touching UMG like it is cancer, especially when you can use TSubclassOf - adding 1 extra line of code to get the class value, and extend your UMG widget without having to even touch the ■■■■ thing. I posted my answer (once again, admittedly in parts) in the other thread - it works. I am now actively using it in my own project and confirm 100% that it works. Just because it doesn’t work for you doesn’t mean it doesn’t work.
The potential reason it might work for me and not for you is that the blueprint UMG class automatically adds a UPanelWidget as the root component. Add the following line just before the GetRootWidget() line.
UPanelWidget* RootWidget = WidgetTree->ConstructWidget<UPanelWidget>(UPanelWidget::StaticClass(), TEXT("RootWidget"));
// If GetRootWidget() is still null
WidgetTree->RootWidget = RootWidget;
The solution was not possible for you because you were too stubborn to look at the anatomy of a UMG blueprint widget. You are just looking for a fight at this point, and I refuse to further help somebody who is not willing to use all of the tools at their disposal or think outside of the box. I’m not taking the bait. Enjoy your evening.
Please keep the discussion civil and avoid insulting each other.
Hi Matthew, even though I provided prove that Shohei is wrong, because he admittedly used widget blueprint (UMG) and NOT pure C++, he still won’t admit that he’s wrong. I guess he doesn’t understand plain English and I should have used alien language with him.
Hi Shohei, of course your solution work because you used WIDGET BLUEPRINT (UMG) and NOT pure C++. I have used widget Blueprint since long ago and did not find any problem with it. If you have read my original question carefully, then you wouldn’t repost this irrelevant answer. If you can’t understand that plain English, then I don’t know how to make you understand it, because I don’t know alien language.
So if you’re truly an expert in UE, please be an expert in reading a question carefully and be an expert in understanding the main concern of the question. You intentionally did not provide the full source code example, because you’re afraid that I will find out that you used widget Blueprint (UMG) all along. What you did is NOT helping, but MISLEADING from the very beginning.
At this moment, I don’t want to use UMG because I need to access, process, & display 64-bit primitive data type (signed and unsigned) in a single class/object (without class inheritance). And this is not supported in UMG. But, I guess you’re too smart to realize this.
So save yourself from further embarrassment, and stop this nonsense!
To everyone else, if you’re wondering about the “other” topic, you can see it in this link. In that link, my main concern is about Blueprint’s inability to support 64-bit primitive data type will have impact on game development (such as widgets).
So the topic in that post, is slightly different than the topic in this post. But somehow Shohei failed to see this differences and intentionally looking for a fight by reposting the same irrelevant answer.
Hi Matthew, could any UE representation declare that building UI in pure C++ is only possible by using Slate Framework? Other than that, it is only possible by using UMG.
It would be relieving if UE staff can make such declaration. So, even after 2 years of improvement in UE (now is version 4.12.5), this paradigm is still valid.
Btw, another reason why I asked this question, is because I wanted to know whether UE had some improvement, by not enforcing the use of blueprint in widget creation, after 2 years since this post:
It was clear and explicit in my question. If you wanted to provide a workaround for my problem, then state it clearly that it is a workaround and not a direct answer. If you declare it as a direct answer, then this is the reason why we have this debate.
I don’t know the alien language you expected, but I hope you fully understand every single word I wrote in here.
I just took a look at the actual topic of the question, as I was only focusing on the rude behavior prior.
From looking at Shohei’s answer(s), I see no use of blueprints in any fashion in his custom UUserWidget class. The only evidence of blueprints that I see is the screenshot that he posted, which is him making a blueprint based off that custom class. He only did this to show you what it looks like when making one. This wouldn’t be needed since, as he has shown in his answer, the PlayerController would be creating an instance of the base class and not the blueprint.
Another thing to add, I’m not quite sure of your reluctance to use UMG blueprints. While I can fully understand not wanting to use blueprint script due to it being slower than C++, using the design part of the UMG blueprints has no impact on runtime performance as far as I’m aware.
If I’m missing something in his answer that is requiring the use of blueprints, please let me know.
Additionally, at this point, this post is becoming more of an argument than a learning experience. Although you are stating your opinions on Shohei’s answer and that’s fine, you’re also personally attacking him. If we can’t keep this topic on point without frivolous language, I’ll need to close it from further comments.
Out of all of my questions posted and hundreds of other daily posts by other users, I’m actually both surprised and honored, that I finally caught the attention of UE staff. Yes!
So to explain more clearly, here’s what I had in mind. I conceive that the network-related technology provided by UE is very sophisticated. But it will be overkill for my current needs. I want to minimize data transaction via network using my own custom-made protocol and network security system. And my backend platform will be simple Java-based servers.
I don’t need vertex data, polygon data, shader data, and other sophisticated stuff to clog the network. Because at this moment, I’m using my own efficient data structure, to be transacted in the network.
AFAIK, doing this network transaction require heavy C++ programming. And since I want to minimize overhead between data transmission, data processing, and data display, I could really use 64-bit primitive data type support in every aspect of the system. But as we all know, UMG or Blueprint or any other terminology you use, do not support it, I’ll have to find a way to enable the creation and manipulation of UI elements in pure C++ codes. This is the main motivation for me to posts those 2 questions.
I provided a complete screenshot of how I tried to do it in pure C++. But
GetRootWidget() is always
NULL. It is not null only when you create a widget in UE editor as a subclass of
MyUserWidget class and apply that widget in the game. If you tried to apply
MyUserWidget class directly, then it won’t work. This is what I had been trying to prove and convince you all from the beginning.
Now, instead of focusing on our debate, could you help to address my concerns too?
What modifications will I need in my simple source code above to make it work, without creating a widget (or any Blueprint) in UE editor?
Remember that support for 64-bit primitive data type is essential for me. If UMG or Blueprint support it, then you can propose that solution for me. Otherwise, you could simply say that it is impossible.
I’m not 100% familiar with what UMG does and does not support, but if UMG doesn’t support 64-bit primitive data and you knew that all along, then why post about how to make UMG in pure C++ code, knowing that it wouldn’t be what you need? I would suggest creating a new post that actually explains what you want if you need further information. From what I’m understanding here, your only option would be to use the Slate Framework as you hinted at before.
Unfortunately I’m not knowledgeable enough on the subject to give some official statement saying that it is the only way to do this. The only thing I can really say with confidence is that Slate is more versatile than UMG but more involved, as UMG is based off of the Slate Framework and made to be more accessible.
Ah, finally a true revelation. Yes!
Actually, I’m not an expert in UE and I don’t know if there is or isn’t a solution for it. All I know is the ConstructWidget function. I thought that there is another set of libraries or API that I didn’t know and I could use to make it possible in pure C++.
For sure I know that UMG and Blueprint does not support 64-bit primitive data types. But I never knew that there is a way or there isn’t a way to create widgets without UMG or Blueprint.
Like I said before, if I had all the answers, I wouldn’t need to post this question.
Here you go mate. This code belongs in the RebuildWidget() method. This code is completely UMG widget free. Note that I forgot to check for WidgetTree validity when setting the root widget.
Thanks Shohei !!
This complete explanation is a lot more reasonable and what I expected from the beginning. Now people will know how to exactly use it.
So it can be concluded that there is no way to create and manipulate widgets purely in C++ (without UMG or Blueprints). If you created a C++ class derived from
UUserWidget class, then you must create another widget blueprint in UE Editor which also extend from your C++ class, and use this widget (not the C++ one) in your
UPlayerController class or any other class.
Should the solution still work or are adjustments necessary in newer versions? I tried it in 4.18. PanelWidget and text are generated but nothing is displayed in the editor or in the game. Only when I setup a BorderWidget or similar in the editor as root, the text can be seen.