Hello! I was testing some stuff out and found out widgets aren’t fully removed when calling the node “remove from parent”. I’m kind of confused because I don’t 100% understand the issue…
I’m using the node “print string” to check if enhanced input actions placed in widgets (such as returning from a menu to the previous one) work correctly, and while they work, apparently the widget is duplicated each time I close and open it again? The text from the “print string” nodes will duplicate each time I close, open and close a widget. So, is the node “remove from parent” really “deleting” the widgets or am I using the wrong node to dispose of a widget?
i’ve seen that type of issue before.
remove from parent doesnt delete the widget.
i personally treat widgets as sub objects of other actors or systems.
and avoid binding events directly to the widget, but rather the owner actor. (except for some simple subsystems).
you’re using the correct node, but you shouldn’t rely on the widget being destroyed, since that’s out of your reliable control.
same for side effects. i try to make widget trigger delegates instead of directly calling other objects’ functions.
but as for the title, im not sure it makes a lot of technical difference, except these kinds of issues, you might prefer to organize them in a way you like to work with.
Thank you for sharing that idea! I’ll explore it in my next project, and I’ve found a workaround that kinda fixes my issue!
So the return input action was the least of my problems, I also have this IA that sets the recommended settings when triggered. It would trigger multiple times like the return IA and it would cause the game to freeze for too long since it was getting loading and applying multiple times. I added a branch with the condition “is in viewport?” to both IAs and now, although they still trigger multiple times, the branch will only trigger as true ONE time.
another idea (that i haven´t tested but could work) is calling the function “GetParent” and check if it’s set. once removed from viewport it should be null. but i’ve read some people had some issues with it. so give it a test, maybe your flag is more explicit and solid.