hey lads, as you know you can do your basic UMG stuff like creating a UTextBlock etc. in c++ but the thing is (based on most tutors i saw) you have to make blueprint based on that c++ code and have those pointers referenced to the objects that you are going to make visually in BluePrint. i know the whole point of UMG is Creating UI with BP blah blah, but i’m going pure c++ for fun!
My Problem is: after i add a instance of my UUserWidget class to the viewport in HUD, the widget’s code is running but none of widgets are visible. gamemode, hud and playercontroller are also running with no problem.
void UmainMenuWidget::NativeConstruct()
{
Super::NativeConstruct();
UCanvasPanel* Root = WidgetTree->ConstructWidget<UCanvasPanel>(UCanvasPanel::StaticClass(), FName("Canvas"));
WidgetTree->RootWidget = Root;
Root->SetVisibility(ESlateVisibility::Visible); //doesn't work
headerTitle = WidgetTree->ConstructWidget<UTextBlock>(UTextBlock::StaticClass(), FName("headerTitle"));
headerTitle->SetText(FText::FromString("-- MENU --"));
UCanvasPanelSlot* headerTitleSlot = Cast<UCanvasPanelSlot>(Root->AddChild(headerTitle));
Root->AddChild(headerTitle);
headerTitle->SetVisibility(ESlateVisibility::Visible);//doesn't work
if (WidgetTree->FindWidget("headerTitle")) //returns true in my case
{
FString printStr = Cast<UTextBlock>(WidgetTree->FindWidget("headerTitle"))->Text.ToString();
GEngine->AddOnScreenDebugMessage(-1, 5.f, FColor::White, printStr);//shows the accurate text on screen
}
if you mean logs from engine itself, no, nothing notable, but if you mean do i get the widget’s name or current ViewPort, HUD or playerController yes they are all right
thank you for answering.
i did make a blueprint based on my code, it showed the widgets that i created in the BP itself but not the c++ created widgets.
well basically everything of unreal engine is all in standard c++ (based on what i saw in the source codes by now), and we have access to the code so we can make a pure c++ of whatever this engine offers!.
i know i’m looking for a way to use umg instead of slate, lets say i want to make a widget class for Option menu items, and i want to make maybe hundreds of those items with making a dynamic array of my class, maybe i want the user to add or remove some of those items but i cant quite get around BluePrint Logic for making such a thing, for now i’m going to try and make it with UMG and C++ and maybe at last make a blueprint based on my code if it’s really necessary, so just for now let’s forget about slates and blueprint. i know it sounds stupid to not use slates when umg is just something based on Slates for making UI more BluePrint Friendly but UMG is so much easier to deal with than slates, i may use this engine for years from now on and i don’t want to be limited by blueprint and stuck with slates nutshell.
when i can make UWidgets and anything related to UI with just c++ why can’t i just use them? i’m sure there is a way
By “pure C++” I mean that you literally do everything in code, including layouts, arranging controls, assigning resources, binding events, handling animations, etc.
Can you do it in UMG with code? Probaly yes, but, well… UMG is created exactly in order to not to do it by hand
I know UMG is easier, but to be honest all this UObject bloat attached to everything, even a little static text label is too much for me (yeah, i know, typical cpp paranoid :D)
The code makes no sense. The point of UMG is to make use of the WYSIWYG editor, there’s nothing to be gained by trying to design the widget in C++ and indeed you shouldn’t be. If you want to create your UI in C++ only (why you would ever want to is beyond me), then you should use Slate. You’ll be fighting the engine trying to do this any other way.
The overhead of UMG widgets is pretty insignificant next to the benefits you get from using it properly. There is UPROPERTY meta-markup available which allows you to bind to design-time widgets/animations in C++ without any extra work (see Widget.h for an explanation). This way you can design your widgets in the UMG editor, while still doing the heavy-lifting code and implementation in C++.
All of the UI in my games has been done in UMG, and the vast majority of it is ticking itself too. Even in UI-heavy games, it’s not even close to being a bottleneck.
I don’t understand why every developer rushes to avoid Blueprint. The ONLY performance cost of Blueprint is the VM and you have to be doing something pretty ridiculous for it to become a bottleneck. Subclassing C++ base classes into assets costs nothing.
Modding and tweaking UI by editing xml/css-like file by anyone(dev or community) without forcing to registering and downloading bunch of ue4 gigabytes and another megabytes of game itself.
Performance isn’t main concern. UI don’t need reflection and GC, so UI don’t need UObject stuff.
You know this isn’t argument.
Me, my father, my grandpa, my cousins smoke cigarettes. Nobody has cancer. That doesn’t mean I can say that smoking is fine.
Because reading and understanding sequential lines of code is much better than tracking blueprint spaghetti wires.
Because compilers are more mature, recognize some patterns and apply optimizations better than any VM.
Because blueprints teach bad practice.
Finally - because people familiar with c++, jumping into c++ based engine want use c++.
Blueprit paradox: Is it good to let someone drive a car without licence? So, why is letting non-programmer writing code is good?
UMG isn’t going to cost you gigabytes. There is no XML/CSS editing in UE4 nor a WYSIWYG editor (crucial tool for UI design) for Slate, so that’s besides the point. C++ Programming is not even close to the same vein as XML/CSS, and it’s unreasonable to expect an artist or designer to be able use Slate - which requires considerable UE4 programming expertise and knowledge. For reference, none of the UI artists or designers I’ve worked with know the first thing about slate.
Performance is always a concern - but if the choice to use Slate over UMG came solely from a performance concern then it was the wrong choice. My point is that OP should not consider using Slate over UMG purely for performance reasons, because they are neglible next to the benefits of a proper UMG workflow. I’m offering advice based on a lot of experience, so it’s very relevant.
Is it good to have an artist writing complex C++ code? Similarly, should a C++ programmer be spending their time designing User Interfaces?
Just because you’re using UMG, that doesn’t mean you have to use Blueprint to implement the functionality UI. The best workflow is to implement the functionality in C++, but allow designers and artists to use UMG to create the widgets.
This can be easily achieved by subclassing UUserWidget, and takes nothing away from the job of the programmer or designer/artist. There exists UPROPERTY markup for UMG specifically for this workflow, and if I’m not mistaken, it’s the same workflow Epic use internally. That video seems to completely disregard a lot of that.
It’s up to you ultimately, but personally, I don’t want to be bothered everytime an artists wants a UI element shuffled around a few pixels. I also want to be abvle to take advantage of many UI-centric features UE4 does have for UMG but not for Slate, such as a WYSIWYG editor, as well as a more suitable communication to game code, and the sequencer editor for animations.
From End-User point of view - yes, UMG cost gigabytes. Maybe I don’t know something, but I can’t see a way to edit UMG in a shipped game/app.
I don’t see the OP mentioning anything about performance. I didn’t mention it either.
Of course not. An artist should not write any code, even the simplest one. The programmer should also not design the UI. But design a UI framework? Absolutely.
This still causes the programmer to know what is to be displayed and how(button/list/label/etc.).
Sure. I don’t care if the button is in the left or right corner, are animated or not. I only provide some ID and the UI guy does what he wants. Just like in UMG, but difference is anyone can do it, not only dev with access to UE and product source.
