Alternative Solution for Creating Back Button Challenge

Unreal Courses Show
,
#1

You don’t need to new function or bindings.

void UMainMenu::OpenJoinMenu()
{
	if (!ensure(WidgetSwitch != nullptr)) { return; }
	if (!ensure(JoinMenu != nullptr)) { return; }

	// Check current widget
	if (WidgetSwitch->GetActiveWidget() == JoinMenu)
	{
		WidgetSwitch->SetActiveWidget(this); // this = main menu - widget 0 index
	}
	else
	{
		// you can active this method (it's safety) or you can active with widget index.
		WidgetSwitch->SetActiveWidget(JoinMenu);
	}
}
1 Like
#2

Thanks for sharing. It’s always good to see alternative approaches.

1 Like
#3

I wouldn’t use that if I were you and I would stick with the instructor’s solution.

Looking at the Unreal code, and since this is not a valid child of the switcher, this call is equivalent to SetActiveWidgetIndex(0) (which I think you’re aware given the comment in the code).

  • As indicated by the instructor in the video, the point of using SetActiveWidget is to avoid assuming that a menu is at a specific index. Your alternative assumes that the main menu is always at index 0. I give you that it’s really likely to be the case, and the issue with indices is more a concern for submenus (Join vs Option vs SelectChapter vs …). However it’s not unreasonable to want to order the menu alphabetically in the switcher for instance., or to want the menu you’re currently editing at the top of the list (index 0) so less scrolling is needed in the hierarchy view.
  • It relies on the fact that Unreal defaults to index 0 when you pass an invalid widget. I do not know Epic’s stance on backward compatibility but if they don’t care too much about it (quite possible for reasons outside the scope of this discussion), it’s quite possible that one day they change the behavior to become a no-op instead using 0, in which case your code will break. You could of course always update your code later, when, and if, Epic ever decides to change the behavior, but is it worth the risk just to avoid an extra binding?

Anyway, just my 2 cents.
Cheers

–
On a side node, I’m not sure how to read the comment “this = main menu”. So to avoid any misunderstanding, be aware that this is not the same main menu as the “main menu” in the switcher. this is more like the “main menu manager”, while the switcher needs a “main menu panel” (a UOverlay, or a UVerticalBox,… that sort of widget).

So a more accurate comment would this = invalid switcher child widget = 0 = main menu panel.
And in that regard, nullptr also works and avoids the confusion of “why-pass-this-when-it’s-not-a-child-of-Switcher?”:

WidgetSwitch->SetActiveWidget(nullptr); // invalid widget = 0 = main menu panel

Privacy & Terms