Hi,
It would be nice if UMG widgets could be based on other widgets as parents.
Pretty much the same way as BPs.
I have a lot of similar based widget elements that do slightly customized things.
Right now I duplictae and twek them individually.
But thinking of potential changes to their common behavior gives me chills…
Such a feature would been nice. The lack thereof completely changed how I implement UMG in my projects. The strategy I now use is to relocate all logic into a single BP Actor (Manager) using wiring up the UMG events to custom events in thw Manager. I dubbed Centralized Processing:
https://arcadekomodo.com/home/wp-content/uploads/2015/11/CentralizedProcessing.png
Motivations:
Even with inheritance I would most likely go this route for flexibilty and rolling-my-own MVC pattern.
Sounds like an interesting approach for handling UMG interaction.
But I would “need” the widget inheritance for the actual widget design.
Like here:
I have PercentileBasicUI widget. Just a background image, a progress bar, a text component and another image as icon.
With a “SetData” function, the user can set the value for the percentile:
(The “Value” and “Total” variables that are set are private)
So, after the value is set, the UI is updated:
The various update functions for each component:
Nothing is done to the icon in the base class. Descendant classes could then overwrite this function to add icon update logic.
Although probably never needed, descendant classes could overwrite this function to modify the displayed bar value.
This is the method that a descendant class would overwrite to have the value displayed differently. For example: Ammodisplay “15/20” Healthdisplay “75”.
So, with your approach, I might be able to move that logic into another class and have my widgets controlled from there like shown in your diagram.
But what if I want to extend the widget to have another text component above the bar to make a “CaptionedPercentileUI” widget?
Sure, I could create a new widget, and drag the Percentile in as a component, but then that gets messy when you rearrange things in the hierachy…
How do you keep changes in your UMG setup in sync with yyour “Manager” class logic ?
Are you talking about being able to reparent to other Blueprint widgets? This is already possible in C++ after all, you just create a new UUserWidget class and reparent to that, and the varying C++ classes can be children of each other.
With widgets, it seems not possible.
When you right-click on a “normal” actor class blueprint, the context menu gives you the option to create a child BP.
this option is not there for widgets.
First I thought it was just an oversight and the menu entry was missing.
When you create a new BP and choose your widget as a base class, it creates a new widget class with your original widget as parent, but the viewport is completely empty and also no “inherited” varaibles are visible/accessible. Its just like a complete new widget BP. No trace of the parent…
The same happens if you choose “reparent” in the UMG editor menu…
You can reparent and inherit logic (not sure why it didn’t seem to work for you), but you can’t inherit widget layout. It would be kind of hard to decide how exactly that should work - it wouldn’t be feasible to be able to remove content added in the parent class, and controlling how new content could be added in the designer and integrated with parent widgets would be pretty difficult to do in a consistent way. I think it would be useful though if there was at least the option to simply inherit the parent layout exactly without being able to modify it, but still add more logic and overrides on the blueprint graph.
Well, it would work like: The child class comes with all its parents components laid out in there. Then you can add components or modify existing ones (moving them around, or make the caption italic instead of regular).
Indeed, hiding controls would be only usefull in edge cases (but they exist).
Well, I cant give you a good C++ example (because I dont know any C++), but it would be like the “TWinControl” or “TCustomControl” class in Delphi.
In the example above, I would take the Percentile widget, create a child, call it “CaptionedPercentile”.
If I wouldnt do anything with it, it would just look like a “normal” percentile, with all its widgets (bar, icon, etc).
I then add a text component to be placed at the top.
Then in the constructionscript of the child widget, which is run after its parent construction script, I would move the position of the (inherited) percentile widget down a bit, under the caption.
Yes, so a quick changein style to the base class would propagate through all child classes.
Imagine you have 50 percentile displays in a screen and then decide to tweak the appearance. You would have to redo the tweak 50 times for each iteration… Thats just not feasible…
Yes, with C++ everything is possible, however, we’re referring to Inheritance aka Parenting in Blueprints.
@KVogler That illustration is more complicated than implementation. Its a one to one wire up from Manager Event Function/Bind Function to UMG Event Function/Bind Function. Moving all of the functionality to Manager, significantly makes navigation functions easier during development and troubleshooting.
https://arcadekomodo.com/home/wp-content/uploads/2015/12/Centralized-Blueprints-Processing.png
Although we don’t have inheritance we have the ability to *nest * UMGs within other UMGs, a sort of stacking inheritance. Until the feature is added, the most direct workaround for UMG inheritance is UMG Cloning.
Appearently 
Maybe you can give me a little example how it would work in the case of my percentile display (from above).
How would I go about stacking/nesting it to make a cpationed version that looks like this?
And of course it would implement another function “Update caption” analogous to the UpdateValueDisplay function.
(overwriting that the user could for example put the caption always in brackets, or quotes, or add other decoration).
I have never used binding and events before. Until now all my UMG widgets were “passive”, like the percentile display or other in-game stats displays and gauges.
Nesting may not be the best option for your purpose. Why not just clone it?
You mean duplicate?
