[4.14] Extended UserWidget has no Designer tab

[anonymous_user_d9f241d9]

I have been using extended UUserWidget classes for some time, since 4.9. I now moved to 4.14 and suddenly there is no Designer tab! What? It works as intended in 4.13!

In my Build file:

PublicDependencyModuleNames.AddRange(new string[] { "Core", "CoreUObject", "Engine", "InputCore", "UMG", "Slate", "SlateCore" });

In my project header:

#include "Runtime/UMG/Public/UMG.h"
#include "Runtime/UMG/Public/UMGStyle.h"
#include "Runtime/UMG/Public/Slate/SObjectWidget.h"
#include "Runtime/UMG/Public/IUMGModule.h"
#include "Runtime/UMG/Public/Blueprint/UserWidget.h"

My new class:

#include "Blueprint/UserWidget.h"
#include "MyUserWidget.generated.h"

/**
 * 
 */
UCLASS()
class MYPROJECT_API UMyUserWidget : public UUserWidget
{
	GENERATED_BODY()
	
};

I then compile and create a new blueprint based on this class and I get this:

There is no designer tab. This is in a blank, new project. Nothing else present.
I looked through the patch notes for 4.14 but found nothing.
What changed?

[anonymous_user_d9f241d9]

I’ve gone back as far as 4.10, and the behavior persists.
Old widget blueprints that I had made work just fine. Anything new does not allow me to edit the design.

I have also tested this on two machines. The behavior persists.

[anonymous_user_d9f241d9]

If you create the blueprint by right clicking on the C++ class and select “Create Blueprint class based on <>”, you will see this behavior.

If you create the blueprint by right clicking in the content browser and “Create Blueprint” and then navigate to the selected class, you will get the appropriate window.

So the first method will produce a Blueprint Class.
The second method will produce a Blueprint.

There is no way to create a Blueprint by right clicking on the class in the C++ class browser.

The difference is between a Blueprint and a Blueprint Class, which are -=NOT=- well differentiated. The documentation even claims that they are the same thing. They are not.

[anonymous_user_b666e59e]

Hi ,

I moved this post over to the Bug Reports section, because I don’t think this is intended functionality. I believe the intention is for the resulting widget to be the same in both cases. I am going to do some additional testing on this and see if I can find out if this is intentional.

[anonymous_user_48f2118e]

Menu Item: Window > Toolbar (Yours will look a little different than mine if you are on Windows)

[anonymous_user_b666e59e]

Hi ,

I entered UE-40853 to report the inconsistent results that you described. I don’t believe this is intended, and both options for creating a Blueprint derived from the custom User Widget code class should result in a Widget Blueprint being created.

[anonymous_user_b666e59e]

Hi ,

It turns out that the workflow of right-clicking on a User Widget code class and creating a Blueprint from it is not one that is supported by the Engine. Sorry for any confusion here.

[anonymous_user_d9f241d9]

Can I then recommend that it not be possible to do? Remove that item from the context menu. If it’s not supported by the menu then it shouldn’t be in the list.

[Sir_Rogers]

Hello , can you please explain then how we are supposed to create a blueprint from a custom UserWidget class in C++? Because that´s what I´m trying to do, and there seems to be no possible way even though it should be.

As right-clicking from the content browser will get me a blueprint class, which has no designer. I want the designer, so that I can add UI elements and place them in the visual designer for my custom class.

[Sir_Rogers]

Credits for the Solution

A new, community-hosted Unreal Engine Wiki - Announcements - Unreal Engine Forums.

In case the link ever stops working

1. Create User Interface → Widget Blueprint

2. Open up your new Widget Blueprint

3. Switch from Designer to Graph View

4. Click Class Settings

5. Switch “Parent Class” from “User Widget” to your custom one

[skyphyr]

The way describes appears to be the only one. Though says the alternative is not supported, but as points out, the option shouldn’t be there then.

There’s a number of these little gotchas hidden all over UE4 where after you’ve spent a lot of time looking for what you’ve done wrong, you find out it’s just code paths exposing unintended options which won’t work and aren’t documented. (Font renderers being another example, where they don’t work with fonts imported using the new method, subsampled fbx import which can lead to surprise bad animation imports, the export to text context menu which puts out files that can’t be imported into unreal engine and have no clear use case, these are just some of the top of mind ones I’ve run into lately). I’m not sure of a fix as a user, but in general, I’d love to see Epic staff responses on forums doing more explaining how things do work, rather than magic steps or defining that which doesn’t work as unsupported. Though, I appreciate, this often means finding someone with specialized knowledge and spending more time on answers. While reading the code helps, it can only ever show us how the code, not the design or workflow intent. Intent is critical to deciding how we structure our projects.

For example, is there a superior use case to the blueprint class construction example? i.e. is the one there in the context menu ever what’s desired? Is there anything it provides which the blueprint widget does not? It seems like it’s just a subset, so has no use beyond a full one. I’d love to hear more on the difference, because it feels close, but not quite the same, as the difference between a C++ class vs an instantiation of it.

[anonymous_user_576f2c0a1 (anonymous_user_576f2c0a)]

Thanks a lot this worked for me!

[50961 (Roy)]

still worked in UE 5.1.1
BP and BP class are different thing