Bound event not firing when called

I’ve been going through the process of setting up widgets that communicate with each other and I thought everything was going quite well up till now and then I ran into this weird issue where this event gets bound, but never gets called.

Here is the event being bound:

And here is the event being called:

I’m in a state of confusion as I have another event that works completely fine that gets bound before this event does:
image

Here it is getting bound:

And here it is getting called:

I have spent 3 hours trying my best to figure this out and I’ve made no progress and I have decided it may be best to get others’ advice since I can’t seem to find anything online to help me.

can only guess from what i see but

when you remove from parent you destroy the widget which means you destroy the binding.

Thanks for the info, I’ll be sure to work around that.

Let me try moving a couple nodes around to try and avoid this and I’ll report what happens.

After some fiddling, I’ve changed the “Remove from Parent” nodes to “Set Visibility” nodes as they provide the same result as removing them from the parent seeing as how the menu is loaded 24/7 in this level anyways.

This has caused some other hiccups I was running into to vanish but still has not fixed the overall problem of the Event Dispatch not calling the “Options Book Opened” Event.

For some better context, If I load up the game, the menu appears as normal and I can seamlessly go between the book and the menu. The problem lies in setting a variable that causes the “Unsaved Options” prompt to appear depending on if you’ve changed a setting since you opened the book.

If you change a setting, it appears, and when you come back to it and leave without changing a setting, it appears again. It’s not supposed to do that.

That’s why I had the main menu calling an Event Dispatch that gets bound to the “Options Book Opened” event to reset that variable as it’s stored inside the Options Book.

The “Unsaved” Event Dispatch works fine even though I call a “Remove from Parent” node after calling the event. Even doing it multiple times makes it work fine. However, the main menu’s Event Dispatch doesn’t trigger at all no matter how many times I attempt to trigger it.

As an aside, from a little later, here are the events called for:

When you access the book, the series of events called for are on the left side.

When you confirm leaving without saving your settings, the series of events called for are on the right.

And yes, I fixed the variable problem by putting it after I call for the “Leave without Saving” line of events. But the main problem is still here. I can’t call the “Options Book Opened” event to get the Game User Settings so that the options reset to your previous settings upon entering the menu after leaving without saving.

sorry its hard to follow out of context so more general advice,

make sure the mainmenu is valid on the binding, also add a print string there just to make sure its called.

make sure you’re binding to the right place, for instance i see you binding to the main menu and calling on the button but is the button a child of the menu?

The button is part of the Main Menu widget, and everything up to the event itself is called.

The node that binds the event gets run, however the event being connected through the red line does NOT get bound.

And as for the reference being valid, this is the setup used to get the main menu without casting to it:

I do it this way to prevent other widgets from being loaded 24/7 so it kind of became a habit.

It’s set up as part of a function so I call to it anytime I need a reference to the Main Menu for any reason.

wait thats a little confusing. you’re pulling the is valid node off the false path which wont be valid (i think, never seen it quite like that before) just use a validated get node on your mainmenuref.

if im right you’re creating duplicate menus and overwriting the ref which will again break the original binding

This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.