I need 2 widgets that both reference to each other, in order to start an animation on one of them. Basically, Widget1 as a button to open Widget2, and in Widget2 there’s another button, if someone presses the button on Widget2, Widget1 should play an animation. The thing is i can only set up 1 reference without the engine crashing. I tried every way, even recreating both widgets from scratch.
Perhaps you force a circular dependency despite of all the counter mechanisms Epic has been implementing over the years. Without seeing the script, it’s impossible to tell what is going on.
Also, no reference variables are actually necessary, you can always dispatch the calls instead.
And how can i do that in my case?
Add Event Dispatcher to each widget, bind them when you create the widgets.
So i create this in both widgets, but what do i attach to “Object”? The widget where there’s the event or the one where you’re calling it? Or do i need to keep it self on one of the two and then call it from the reference?
Actually im confused…
This is what you were trying to do:
Pretty horrible to look at but it will work.
How is it supposed to work? What are we making? Are you clicking a button in widget A and want B to receive the call and vice versa or something more complex?
If it’s just buttons:
- both widgets have a custom event and a button:
- when you create widgets:
Admittedly, it is still horrific to look at. Perhaps you could tell more? if both widgets belong to the same parent, this can be dramatically simplified…
Yeah, how is it supposed to work? I’ll try to be more specific about my situation: Widget A has a button that adds to viewport Widget B. In widget B there’s a button that when you click it, it should call an event for Widget A where you start an animation. For Widget A to open Widget B i use a reference to that widget, and to call the event for Widget A, i need another reference, but that doesn’t seem possible in my case. So like this “event dispatcher” that you mentioned, i never used it nor heard about it. That’s why i’m confused.
Will this then work out with my case?
They don’t belong to the same parent, they’re 2 completely different widgets. I’ll try with this
Widget A has a button that adds to viewport Widget B. In widget B there’s a button that when you click it, it should call an event for Widget A where you start an animation.
Thanks for the details - this is a much simpler case of:
Buttons already dispatch calls so no additional calls, custom dispatchers, variables or binding is needed. This is the use case scenario for which Event Dispatchers exist.
Sorry for the delayed response. I didn’t cover a little thing. So this actually works, but there’s a problem: i have a bool variable that if it’s true, than the button need to work, if not the button doesnt have to do anything. The variable is stored in Widget B. If i try to make a reference to that widget it doesn’t pass the updated value. Basically in Widget A the variable from Widget B is ALWAYS shown as false, even if i change it to true
Add a custom event dispatcher to widget B and have the button call the dispatcher or not based on the state of the boolean. Instead of binding to the button’s onClicked, bind to the custom dispatcher.
You can also add any data to dispatchers if it’s more convenient to handle true / false in widget A.
No need for a variable, especially that it is null here. However, if you do need the var for something else:
Also, you can:
Instead of Delay. While we can interrupt an animation, we cannot interrupt a Delay which can become a little nightmare to debug at times. Probably irrelevant here.
So the good news is that now the event dispatcher works and starts the event, the bad news is that the “Play animation with Finished event” doesn’t work when plugged on Finished, only works with the other pin (tested with print string)
Did i miss something?
Thank you so much! Everything works fine now. What should i mark as solution for this post?
1 Like
That is completely up to you. Cheers!
This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.