I would love (and desperately need) the ability to natively create child widget blueprints. Somewhere Icame acroos where it seemed like this functionality could be added by adding a little code to the engine, but I do not want to mess with C++ at this time and would like to keep my project Blueprint only.
If I could simply create child widget blueprints like you can by right clicking a normal blueprint, I could then easily setup an advanced menu/window system that would make creating a complicated menu/window system easy to do as I could make the scripting self sufficient. But as it is now, there is not a way to set properties and scripting that would be common to all widgets (such as rollover behaviors, functions for clicks and user interaction, colors etc.) and then be able to creat a child that would have same behavior plus some unique behavior, and if soemthing changes in parent, I would not have to go back and change all my widgets by hand. This would also give me the ability pass variable information to other blueprints where it is currently not possible to have a variable reference a parent widget class, you can only reference the user widget class or the specific class of the widget. Hope this makes sense?
You can do this by creating a widget blueprint and changing its parent class in the class defaults panel. There is a dropdown menu that has the native parent class (defualt UserWidget) displayed. You just have to click the dropdown and select your desired parent widget class. The only caveat is the parent widget cannot contain any elements in the widget layout. It can only contain code. I’m not sure why it’s not exposed in the right click context menu for the user widget class, but it should work either way.
Let me know if you have trouble finding the class defaults panel.
what do you mean by " you can only reference the user widget class or the specific class of the widget" ? you can always reference and pass variables around - if it s parent/child or not doesn’t matter. you can also use umgs inside other umgs (for menues) like you already do with buttons (look at child widgets and custom widgets), and you can inherit from your custom widgets (so parent defined functions, events, variables… are available to you childs) but not add additional widgets to your childrens widget layout. if you like to store some global variables, use datatables or data assets - if anything fails gameinstance, savegame etc… lots of possibilities and for reparenting use File->Reparent Blueprint
Hey thank you so much! This does help, some, but not entirely. This is much appreciated as I did not even think to look to try this! This should help me with some code, but unfortunately where the true power comes in is in having parent layouts ;( But this should help some at least with not having to recode common behavioral code!
Yeah, I already realize all this, but thanks for trying
I’ll try to explain better: Because I cannot use widgets in layout of Parent, this is extremely painful because I would want to setup a parent with layout elements, and then child would inherit those elements and all elements of child would be direct children of parent elements. Think of a window, you have the window area which holds all the information, an then the window header which would be in the parent and the header would contain the close, minimize and maximize buttons. This way, if I alter he layout of the parent (changing header visuals etc.) it would change all my headers. Yes, I can place a User Widget in another widget, but this gets complicated accessing variables and elements insid the child. And I have found it complicated (doing loops) to get the outer most parent widget. Also (before I saw @F_Innovations comment above) I did not have a way of saving a widget in a variable as a particular class of widget so I would not need to cast (cause I would not always know widget class to cast to) but now that I know how to set parent for code purposes this should hopefully solve that problem for me. Simply put, if it were possible to have widget layout elements in a parent widget, it would be extremely easy to setup complex widget systems that would allow extremely fast iterating of designs and design choices and functionality as well as simply drag and drop elements to create a complex “windows” system that would be self contained, in other words I would not need to read/write to variables in gameinstance. This probably still isn’t very clear huh? Let me know if this still does not make sense, as I truly would like to understand a solution if one exists (which I guess the having parent widget layouts does not) or to have this be clear to have the best chance possible of Epic picking this up and implementing the functionality. It would be a HUGE asset for an app I am working on.
How about instead of a parent widget class of which child widgets inherit layout, have a base widget class that can be templatized (for lack of a better term, or rather, preconfigured with layout set yet modifiable). Then there’s not the limitation of reconstituting parent classes for every variant of window layout, and other functionality. It can receive and output any widget-based entity / object in C++ and blueprints, and doesn’t require a parent/child setup to operate correctly. Parent/child setup is usually limited to a tree structure, so a base class model would be more similar to web design and allow new functionality and structure types to be constructed and modified on-the-fly and pre-planned. Perhaps I’m simply speaking out of turn, though, as C++ is a more difficult language, according to the programming experts.
The closest thing that I’ve been able to come up with is to create base properties for panel widgets then use those properties to add children, set screen positions, handle events, etc using base functions that get called in the child widget on construct (or whatever event kicks off your widget).
For example, my inventory layout holds a reference to the grid panel that contains the inventory slots and holds a base function that goes and adds the desired number of slots to the grid panel.
On my child widgets construct event I set the grid property to my inventory grid panel, then I call the function to create the grid.
I still have to manually set the layout in each child widget, but that is what the child widgets are for anyway so it still works out!
preston42382 mentioned something similar in their comment, but I wanted to share my setup too.
Not sure I understand what you mean by " reconstituting parent classes for every variant". Ideally, what I would be looking for is the same functionality in widgets as we get with typical blueprints. If for some reason (I currently do not understand why this would not be possible) it is not possible due to underlying C++ engine coding resaons, Templates was the next best thing that I was thinking of. Maybe this is what you are describing, but what I was thinking in terms of Templates, was that you could create a layout template (and since you can already set a blueprint parent for the code, the template system would only need to handle layout), you could then select that template and it would apply it to the “child” of that template. The important factor is not just being able to select a template (I could technically already do this, just make a layout and label it “_Template” then duplicate that template to create a new widget) but having the ability to EDIT THE TEMPLATE and then those changes would propagate over to the widgets using that template. And, perhaps its possible to make a plugin, or use Blutilities, but a work around is not what I am after. I am after a legit built in native system .
Huh, your making me think of Material Collection Parameters. What about Widget Collection Parameters? This would be a great way to have a collection of variables to use in widgets. Say, I have a collection of Colors, Font Sizes, basically and widget parameter that can be a variable, and that way one would be able to editthe colors(variables) in collection and it would propagate to the widgets referencing those variables. Although, now that I think of it, I suppose using a Data Table would be the same thing yes/no? An actual Widget Collection Parameters Asset might just b a nicer way of implementing it and faster than reading a Data Table. This woul make quick and easy to make design changes such as fonts, colors, hover settings etc.
Nice to see someone who understands where I am coming from. One thing I see happening is the same thing with child actors. Placing a child actor in an actor you cannot directly access (from what I know of) the functions and variables in that child actor. I guess that would be the relation to how current widget system works? I would really like tto be able to create a Parent CLASS which has layout; and easy way to get root parent from a child widget. If I create a menu button, I place that menu button widget as a child widget (child “actor” per se, not child of parent class) inside menu widget, I can have blueprint script in child widget access and get reference to parent, that child widget blueprint script can call the “remove from parent” node on it’s parent widget (to close the current menu, and then open a new menu or submenu of class (class is set via variable in editor at construction). Since it has a reference to it’s parent widget, can pass that reference to the menu/submenu it opens so when you click a “Back” or “Close” button on the new menu/submenu, it will know to add the old widget (parent widget of the child widget that opened the new menu) to the viewport. This would enable a completely self contained menu/window system, which could be easily migrated and mnaged/cchanged/built. I have managed to get something similar to work by holding a Map Variable “Menus” (Name->UserWidget) on the GameInstance. The “Open Menu” function is on the GameInstance so when it opens a new menu and creates the widget for the first time, it sets the Name (Received from widget that called function) and the reference to the widget it created. Now I can check this Map Variable to see if the widget exists in memory before creating . I also have a Map variable Name->UserWidget which holds a single item, reference to the Previous Menu, and my back button calls “Open Previous” on GameInstance, so I can close curreent menu and reopen the pevious menu. Whew, thats lengthy, sorry.
I was getting at what you said about having to call not only the adding of the child widget, but also its removal. One of the “problems” with parent / child inheritance is it quickly turns into a tree structure, where in order to modify existing inheritance there needs to be pre-written instructions to add / remove inherited traits (in this case the traits would be layout properties and functions). And it’s always then bound to the parent, which if it is not modified correctly, can result in child instances becoming more tedious to clear of unwanted traits and adding wanted traits. With a base class, it would be similar to a template or modular system that doesn’t require such a ton of restructuring of inheritance at more complex or deeper levels. It would involve, as you said, duplicating or perhaps instantiating the base class layout (and anything else selected for in the base “class”…denoting the C++ class term), then modifying its properties and functions. So multiple base classes could be created with certain properties and functions already set, and then instantiating or duplicating that for designing a particular layout while retaining those properties / functions and adding and modifying new ones. It’s to get rid of the necessity to call the parent class, then remove certain child widgets / inherited traits, then add new ones…and then do it all over again for a completely new interface or part of the interface. That way it’s not bound to the parent in every aspect of the menu / window system that is to be developed. Several or more base classes could be created from the start that are intended for designing several or more different aspects of the interface…all without having to reference the parent class and continuously alter its inheritance over differing iterations.
I’m not on my of rn but, like when you click classsettings/under interface/click add interface/then compile/then on left drop down the interfaces tab/ then you will see your added interface and you will see its gold and can’t be opened why is that?
One of the “problems” with parent / child inheritance is it quickly turns into a tree structure, where in order to modify existing inheritance there needs to be pre-written instructions to add / remove inherited traits (in this case the traits would be layout properties and functions). And it’s always then bound to the parent, which if it is not modified correctly, can result in child instances becoming more tedious to clear of unwanted traits and adding wanted traits
Not sure I am following you correctly - you are talking about Parent/Child Tree Structure in the widget editor?
I tried making a “Class” that I could put my script in, then making a widget and setting its class to that widget class. But then I ran into the issue, because only one (Parent or Child) can have a tree-structure, the script needs to reference layout elements (Text, Buttons etc.) which, if the layout is to be empty in the parent, cannot reference, or if I Put those elements in the parent so script can reference, I cannot put anything into the child, so now at this point I do not follow what the point is in setting a “class” for the widget, although for very basic scripting which does no have to reference any layout widget elements.
So multiple base classes could be created with certain properties and functions already set, and then instantiating or duplicating that for designing a particular layout while retaining those properties / functions and adding and modifying new ones
So if widgets have a tree-structure that of Actors, I can create a Parent Class with “Components”, and when I create a Child Class, it inherits those Components, and code written for that widget (lets say the “Window”) will function. But then in the Child Class, I could add more components that relate to that version of the parent (a specific stylized “window”) and keep the functionality of the parent scripts. Like in Actors, you have to remove elements from the Parent that exist on the parent.
and for reparenting use File->Reparent Blueprint