As of 4.8 you can no longer derive a user widget and have access to UMG
Hello ,
I was able to reproduce this issue on our end. I have written up a report ( UE-17133) and I have submitted it to the developers for further consideration. I will provide updates with any pertinent information as it becomes available. Thank you for your time and information.
Make it a great day
This method has never worked and it’s not supported. You can’t make a UserWidget with a designed UI, then attempt to derive from it again. It’s unclear what the expectation would be. You can make a UUserWidget in C++ without a widget tree, then reparent a Widget Blueprint to the user derivative of UUserWidget in the editor.
Additionally, constructing a Blueprint from the perspective of the editor is different from creating a Widget Blueprint, they’re entirely different classes.
I had a widget with a function on it, which I could call on the derived widget, without the ability to derive I would have to manually recreate that function on every widget.
In 4.7 I had a system setup so that my top level widget would call an update on all its assigned children, which would alter them based on a gamestate. This made switching from a menu or submenu to game and back with correct transitions all work flawlessly.
The move to 4.8 made some of the derived widgets crash when i try to open them, one of them didnt crash and still had the UMG interface, i duplicated that a bunch of times and have setup my system again in 4.8 and its working fine.
P.S. the working derived widgets only work on PC, they make the IOS build crash.
Hello ,
Thank you for the additional information, however as Nick mentioned above this is not a supported method for the engine and so the report has been marked as “Won’t Fix”.
Oh… is there any reason for that? Inheritance is a pretty core part of programming so I’m a little confused as to why this is a special case.
We support inheritance of the UserWidget via native code, (Possibly via standard blueprints, but that’s untested). However, in either case, UserWidgets must eventually be derived using a WidgetBlueprint, as it configures a bunch of things necessary for proper initialization. I may have fixed this in 4.9, but users trying to author user widgets entirely through code was not a design goal.
The limitation currently is you can’t design a widget tree in the base class and attempt to inherit with that widget tree and then attempt to build off it.
There’s no concept of ‘Master Pages’ as people have come to call them in web design. Eventually maybe, but not right now, what you’d need to do is build the dialog appearance/chrome as a user widget, and give it a named slot where you want to insert content. Then for each dialog insert the chrome, and then insert some content into the named slot.
Alternatively you could make a dialog widget with an exposed spawn parameter for TSubClassOf< UUserWidget >, and then create the content when the dialog is constructed, and insert it as the content of the dialog, into the widget hierarchy.