Are there other ways to bind UMG Widget properties?

Development Programming & Scripting UI
, , , ,
1

I have a custom UUserWidget (let’s call it UDebugWidget) that has some other common widgets (UImage, UTextBlock, etc) that I’d like to expose some property bindings for widgets that it’s composed of. These bindings should be accessible via C++ and the editor.

For example in C++, STextBlock supports void SetText( const TAttribute< FText >& InText );, however, the UMG version UTextBlock only supports a simple FText parameter via virtual void SetText(FText InText);, which won’t work for all cases. Is there a way to work with attributes in code for UMG similar to the way it’s handled with Slate?

In terms of editor functionality, I can bind properties in the blueprint editor for ‘UDebugWidget’ widgets (ie images, text blocks, etc), but there doesn’t seem to be a way to bind/override functions for instances of UDebugWidget in other custom UUserWidget blueprints. I’m trying to set some default property bindings and override them when that widget is re-used in many other places.

What’s the intended work flow for these use cases?

2

Maybe I’m not understanding something here, but can’t you create your WBP_DebugWidget widget blueprint, give it some custom variables, apply default values to those variables (if necessary) in the widget’s On Construct event (or similar), and use this WBP_DebugWidget as a child widget in another custom user widget blueprint?

And then, in the higher “parent” widget’s graph, couldn’t you change the child WBP_DebugWidget’s properties and variables (assuming they’re public) directly, or otherwise change things on the child WBP_DebugWidget by calling up any custom (public) blueprint functions you may have added?

I really might be missing something, because I’m not sure why you’d need to override any functions just to change the member properties of a child widget blueprint object. (Though overriding blueprint and C++ functions in your derived blueprint classes is obviously very doable, and easy, if you really do need to do so.)

If I’ve got the wrong idea, let me know, and I’ll try to take another shot at helping.

3

I think you have a good general idea, however, I’m looking into property bindings (ie the UWidget data that has a “Bind” option in the Editor) which are handled differently from what I’ve seen. To be more specific, I’m trying to do the following:

1 - Create a UUserWidget Blueprint (let’s call it UDebugWidget again), add a UImage as a child, and then directly access UImage property bindings from the parent blueprint that has an instance of UDebugWidget. If there’s a way to expose property bindings, I can work around this by hooking up some UDebugWidget BlueprintCallable functions that use those property bindings directly, but that’d lead me to #2.

2 - How do you create new UUserWidget Blueprint property bindings? I haven’t seen documentation for this anywhere so that leads me to believe UE4 doesn’t want you to do this currently.

I probably shouldn’t use the term “overriding functions” as all I’m trying to do is modify property bindings in the parent blueprint.

4

I get it now. Thanks for the further explanation.

I think you may be right — there’s no obvious way to access or change the bindings for a property outside of the owning widget itself.

But I wonder if there’s not a better solution to your problem that avoids this difficulty altogether.

Is there some reason why, in your case, you can’t just use custom-made public functions in your ‘debug’ widget to apply changes to component properties as needed? Here’s an example of what I mean.

Let’s again use the same setup: a UUserWidget object, blueprinted as a widget blueprint, that we’ll call WBP_DebugWidget. Inside WBP_DebugWidget, we’ll add an Image, which, for this example, we’ll call “TargetImageWidget”. And let’s assume we’re placing one or more WBP_DebugWidgets into a ‘parent’ UUserWidget blueprint that is added to the player’s viewport. Let’s call this ‘parent’ widget “WBP_Parent_GUI”.

Now say I want the TargetImageWidget’s ColorAndOpacity property to lerp from white to yellow, then back, to give the sense that the image is pulsing with a highlight or something. But say, in some cases, I might want to speed up the pulse rate, or use pink instead of yellow — or who knows what else.

We can establish default behavior, and allow ourselves to customize behavior from the outside (like from our WBP_Parent_GUI widget), by defining a ‘Pulse’ function in the WBP_DebugWidget itself, whose behavior depends on public variables — like a float for the rate, a FColor for the highlight color, etc.

Our pulse function could be bound to the ColorAndOpacity property in the usual way. Any additional behavior modification we might later need could be achieved by adding more public control variables, and more corresponding conditions to the pulse function.

This is surely not the most exciting solution, but it seems to me the most straightforward. Hopefully it proves helpful.

But I might still still not be understanding the constraints of your situation. Guess we’ll see.

5

Yup, this is exactly what I’ve settled on for now until I can find a better method. And to handle the c++ side of things, I just have a couple of TAttributes inside my class that are used by the blueprint callable functions, and owning widgets can override these TAttributes as required. It’s a bit of a…callback calling a callback scenario but it works for now and I suppose the encapsulation makes things simpler as well.

It’d be nice to know if there are even better ways of approaching this though.