4.7.6 UMG -CreateWidget Output issue

Hi,

If you use the CreateWidget BP function and select a UMG Widget asset, the output pin is Cast automatically to your WidgetAssetClass.
If you are using a Class variable as an input, then the output is just “UserWidget” and not your class.
In fact my class variable is a SubClass of UserWidget, let’s call that Widget_Base. On this class, I added a function that I want to be used for all my Widget.

In the CreateWidget class property input, I link my variable. As the ouput, I was expecting to see a Widget_Base node.

Are you able to repro this?

Thanks,

Hello,

After reading over you post and if I have understood you correctly, I believe that this is working as intended. Passing a variable in to the create widget node means that this variable could be changed at a later point and so you would not be able to directly reference a specific widget. I am going to go ahead and mark this question as answered, if you feel this is not the case or that I misunderstood your post please feel free to elaborate further in a reply.

Questions for reply (if needed):

  1. Can you reproduce this issue in a clean project?
  2. If so, could you provide a detailed list of steps to reproduce this issue on our end?
  3. Could you provide screen shots of the issue?
  4. Could you elaborate further on the exact nature of your issue?

I think you didn’t properly understand the issue there.

The variable we are talking about in this topics is “Class” variable and not a reference to an asset. That’s mean that the Widget that can be created can be based on the Class it self or a class that inherits it.
So in all case, the output of the CreateWidget can be casted to the InputClass type. You can see that as an interface if you want.

In our sample:
if you have a c++ class Widget_Base (that inherit form UserWidget), the output of the create widget will be a Widget_Base or a child of this function. When you create the Class Variable you select the “Parent” class. It’s the equivalent ot SubClassOf<> in C++.
So the ouput node should be a Widget_Base node and if you want to acess child only property, you can cast it.

As of today the output is a UserWidget, so I need to cast to Widget_base to get my properties/function.

I hope this is clear enough for you to understand the issue and repro it.

thanks,

Hello,

After looking over your second post, I reached out to a couple of developers for a second opinion and they came back with an answer that was similar to my original post. This functionality is intended. If you are using a variable, how is the engine supposed to know what type it will be at compile time? If you have your class variable referencing a widget with children, then how is the engine supposed to know which child if any you want to cast to? However, you could still cast manually to the specific widget you need. I hope that this information helps.

Example:

Make it a great day

Hi,

Thanks for the feedback. My request was not to cast to a child class as there are no way to know this but to the parent class as you know the information.
When you set the class variable, you know what the Class output node will be so you can output it without expecting the user to do it.
My request is just that, cast the output node as the Class input variable.
Unless I miss something when you create a Class variable, you define a “SubClassOf” property value. This value should be used as the output node definition.

I hope I’m clear enough. I will try to put some screen shot later on to clarify the situation.

Hello,

With the new information that was provided I took another look and I think I understand what it is you are requesting. I have written up a report ( UE-15223) 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

Hi,

Any update on this?

thanks

Hello,

I went ahead and double checked on this issue for you and the status for this issue has not been updated to fixed as of yet. Thank you for your interest in this issue.