A question about widget inheritance

Hi all!

I tested creating a widget with a button (only the button, no other components in the hierarchy), then i created a new widget, and, in the class settings, i changed the parent class to my previously created blueprint.

I supposed that, due the fact the second blueprint inherits the first, and the parent blueprint had a button in the hierarchy, this button would appear in the second widget hierarchy, but… only the canvas is present.

This is normal or maybe is a bug? The widget hierarchy tree isn’t inherited? :S.

See ya!

Bump!

Nobody has an answer? :frowning: .

See ya!

I have also created widgets and child widgets like this. Only variables and functions are carried over to the child.

The actual widget setup was not copied. I don’t know if this is a bug or simply not possible in the way inheritance for widgets works.
You can simply copy past the elements if this is all you need to do fix.

Thanks for the answer :), i’ll do that for now.

I hope this will be possible in the future. The hierarchy tree must be just one of many variables that the widget class has, so it should be possible to be inherited.

See ya!

Hello again, i have done some tests, and i have realized something… that i didn’t expect :S.

I have created a widget with an scrollbox. The “variable” checkbox is ticked.
Next, i have created another widget that inherits the first.

Knowing that the parent widget’s components aren’t inherited, i tried creating a new scrollbox in the second (to replicate the first widget’s hierarchy), but the UMG editor tells me that… a variable with the name ‘scrollBox’ already exists :S.

So, the scenario is… one widget with a scrollbox component, and a second widget, inheriting the first, with an empty hierarchy, but with a inherited scrollbox variable :S.

I would love if a programmer could examine this and tell me if it is a bug or normal, because… i find this quite weird :frowning: .

See ya and good summer!

Resurrecting, due to apathy from developers.

What I’m trying to do is actually very, very simple. I’ve got a parent widget class that inherits from U_UserWidget, named ‘MY_UserWidget’.

Now, let’s say I’ve made a background that is going to be the same for all widgets that I use. I place it in the designer, it’s an Image, I set it up, everything is fine.

Next, I make a child of MY_UserWidget. What I’d expect is to have all the variables, functions and **design **from the parent to be there. I get all functions and all variables that are NOT from the designer and no design at all.

I’ve got 150+ screens of UI that all share elements, slate styles are one way, but shared widgets are not going to work this way.

Now imagine there’s no z-order between widgets, all you can do is make ONE MASTER WIDGET and create ALL 150 * whatever widgets INSIDE it. Of course it’s impossible to do by hand, so I tried spawning them in.

And guess what? Widgets forget their designer variables and spawn as 0px * 0px at 0,0 with everything reset.

So on the MY_UserWidget I’ve added ‘customPosition’, ‘customSize’ and ‘customAnchors’ variables, and on child construct I reference them and set those values manually. But it doesn’t work every time because of reasons (I presume the DPI Scaling), there are constant errors when I change one variable on one child of a child of a child, the whole chain breaks down and everything is broken, because when you set the size of an element to 1920x1080, when you change to 16:10 resolution it’s not scaling properly.

So my question is: how to make a 150+ screens UI with a lot of tabs, screens, popups, tooltips and generally complicated thig, when there’s no inheritance that works?
When (and even IF) it’s going to be fixed? People are talking about it for over a year now and there’s no word on it.

https://forums.unrealengine.com/showthread.php?78458-REQUEST-Widget-Children

Let me know if I can be of any help, I’ve figured out SOME workarounds, but all of them are very manual and hacky and will make a designer rip his hair out having to setup the widget elements and then setup it’s exact position and size, anchors that don’t make any sense and it will still look bad.

I’m sorry if I sound bitter, I am, I get paid to do this and there’s no progress.

I understand your frustration, UMG is one of most messed up and complicated modules in Unreal. It is quite good module, but compared to how good other unreal modules are, UMG looks like done by microsoft, not Epic.

But i am posting here to warn you: “do not push unreal to the limits (in this manner)”, this will bite you later, and bite hard.
I had similar ideas (but for actors), i heavily used enums, inheritance, function library. Yes everything looked pretty, and worked for a time.
Then something happened (one too many custom functions introduced circular dependency) and at that point my whole project got corrupted in many weird ways.
Because i overused advanced features of blueprint i could not migrate it to new clean project. I could not search for all those enums and custom functions to replace them with simple and safe versions. So my project was kind of ruined, and i started over new one. All i could do was copy/paste blueprint graphs and recreate all logic in new project.

So be careful while it looks like great way to solve some problems, you are making your project quite unstable and easy to mess up.

So let me get this straight, your suggestion is to… not do this?

All I need to know is: is there a way to do something like this reliable (I mean a complicated UI with possibly hundreds of views)? Or alternatively are devs on it / it’s not being worked on?

Devs are cleaning a lot of those bugs, but for them is like whack a mole, they fix one it pops in another place. However they cleaned a lot recently (i think 4.8), but my warning is still there: do not make fancy code in blueprints if you can make it another way.

I can do C++, the problem is that I don’t know if it’s even possible to make a robust system in a sensible amount of time. Creating one screen with about 50 elements with Slate from code would take a loooong time, even before I tell designers they need to learn to code. Making 150+ screens like this seems impossible.


@Ragir
150 screens is a lot. Another option you have is to use composition. Which is the model slate was designed around. You can build fragments of screens and use named slots of injected widgets into the fragments. You can make singular widgets that factory children based on class name at runtime. So don’t make 1 popup class and inherit it 30 times, to create 30 popups. Make 1 popup widget with a member variable that’s settable on spawn that’s like “ContentClass”, that’s a UUserWidget class variable. Then on Construct of the popup, you’d CreateWidget of the ContentClass, and inject the content into some container widget in the popup.

There’s a plan for inheritable hierarchies, but they’ll work like slots in any other templating system. You’ll use the Named Slot mechanism that already exists to allow embedding content of composed widgets, and use them in inherited hierarchies as well. With a bit of work, you could potentially make a primitive version of this work in the designer, that just scans for one named slot, and figures out it needs to embed the tree, into some specific named slot instead of throwing out the old and replacing it with the new one. You’d make it so at design time, it doesn’t let you edit or see the inherited hierarchy (for simplicity reasons), then you’d just inject the inherited tree into the super classes tree.

Also, over a year may sound like a long time, but UMG only started a little over a year ago.

It looks like it’s this or embedded chromium and HTML, which is probably a better choice with that many UI elements and with it being separate form the gameplay. I’ll try to figure something out with embedding content, might work pretty well. Thanks for replies, I hope this helps someone researching this topic :slight_smile:

@NickDarrel
Just explaining my opinion: I learned most of unreal modules, and UMG was (for me) so far hardest one to understand. Esp. when you try to use touch interface with it. It is like using MFC library to make simple fire button. You can do cool MS office type things but doing very simple things is just kicking with the horse. I think making MMO or RPG interface would be quite fasy and easy, but for eg getting accurate coordinates of where did i touch that button (or image) is not so simple. (eg. you have circular button in square button box, so you want ignore everything that is outside circle) Doing simple display text (or buttons that work exactly like umg assumes) is very easy, but try to do something that is not necessary exactly like UMG assumes.

My worst nightmare (that i could not solve in umg): simple fire button, in multitouch interface make button that is ON when any finger is pressing it and OFF when no fingers touch its area. This simple thing forced me to write my own touch interface that traced all fingers, gestures etc. Now i use UMG like HUD only to display information, which is shame because UMG has all that and much more implemented.