Popup Levels and How They Work

[dumbasaroc]

So I've been messing around with Popups, more specifically Modals, and was confused by a concept called a "PopupLevel." My question is what are PopupLevels and why does this work:

void SmashScoreboard::DialogWindow::perframe()
{
	if (this->isVisible)
	{
		ImGui::OpenPopup(this->dialogTitle.c_str(), ImGuiPopupFlags_AnyPopupLevel);

		ImGui::StyleColorsLight();
		ImGui::SetNextWindowSize(ImVec2(-1, -1), ImGuiCond_Always);

		if (ImGui::BeginPopupModal((this->dialogTitle).c_str(), &this->isVisible))
		{
			if (this->iconImg != 0)
			{
				ImGui::Image((void*)this->iconImg, ImVec2(64, 64));
				ImGui::SameLine();
			}
			ImGui::Text(this->dialogContents.c_str());

			ImGui::EndPopup();
		}
	}
}

...but not this:

void SmashScoreboard::DialogWindow::perframe()
{
	if (this->isVisible)
	{
		ImGui::OpenPopup(this->dialogTitle.c_str());

		ImGui::StyleColorsLight();
		ImGui::SetNextWindowSize(ImVec2(-1, -1), ImGuiCond_Always);

		if (ImGui::BeginPopupModal((this->dialogTitle).c_str(), &this->isVisible))
		{
			if (this->iconImg != 0)
			{
				ImGui::Image((void*)this->iconImg, ImVec2(64, 64));
				ImGui::SameLine();
			}
			ImGui::Text(this->dialogContents.c_str());

			ImGui::EndPopup();
		}
	}
}

(For reference, in both examples, this function is the update function for a window class. Each class has a bool isVisible that dictates whether or not the window is shown. If it's not visible, the destructor, which contains CloseCurrentPopup(), is called.)

[rokups]

A popup stack is maintained, it tracks nested popups. ImGuiPopupFlags_AnyPopupLevel is meant to be used only with IsPopupOpen() (read comments near enum). I do not see how passing this flag could have any impact, but i suspect issue is somewhere outside of posted code snippets.

Also calling ImGui::OpenPopup() on every frame is a bad pattern. It happens to work in this case, but you may end up in a situation where you cant get rid of a popup if its called on every frame unconditionally. Better way would be calling it once when you intend to open a popup. ImGui::BeginPopupModal() may execute unconditionally as well. It will not render anything if popup is not open.

[ocornut]

+1 to everything Rokups said.

Use the Tools>Metrics/Debugger window to see how the PopupStack is maintained.

[dumbasaroc]

So my problem isn't that things are unable to close (everything that I want to close does so). I'm using a relatively class based system where each class (in this case, they're all windows) has a perframe function that basically renders the windows through ImGui. I then have a std::vector that keeps track of these windows and calls perframe each frame. If their &isVisible boolean is false, it destroys the object. I have a Modal class (that being the example code), and before coming to this, I tried calling OpenPopup in the constructor of the class, and ClosePopup in the destructor. The destructor code worked (and still works), but calling OpenPopup never did until it was in the update loop. Why is that?

[rokups]

ImGui functions operate on ID stack. Calling it somewhere in a constructor most likely calls it outside render poop, with no active window and no ID stack. I am surprised you didn't get an assert. See https://github.com/ocornut/imgui/blob/master/docs/FAQ.md#q-why-is-my-widget-not-reacting-when-i-click-on-it

…

On February 2, 2021 20:06:52 PSMusicalRoc ***@***.***> wrote: So my problem isn't that things are unable to close (everything that I want to close does so). I'm using a relatively class based system where each class (in this case, they're all windows) has a perframe function that basically renders the windows through ImGui. I then have a std::vector that keeps track of these windows and renders them each frame. If their &isVisible boolean is false, it destroys the object. I have a Modal class (that being the example code), and before coming to this, I tried calling OpenPopup in the constructor of the class, and ClosePopup in the destructor. The destructor code worked (and still works), but calling OpenPopup never did until it was in the update loop. Why is that? — You are receiving this because you commented. Reply to this email directly, view it on GitHub, or unsubscribe.

[dumbasaroc]

I did get an assert when I tried it in the constructor, hence why I went into the update method. For the way I'm doing things, this is the only way I've found that works correctly, however I'd be open to suggestions.

[rokups]

We usually do this:

if (ImGui::Button("Open Popup"))
    ImGui::OpenPopup("My Popup");
if (ImGui::BeginPopupModal("My Popup"))
{
    // <...>
    ImGui::EndPopup();
}

What happens here is that we render a button, and a popup, but popup remains invisible as long as it is not open. Clicking a button calls ImGui::OpenPopup("My Popup"); on the frame when button was clicked, and from them onwards popup will render until closed. ImGui::OpenPopup() works here because it is on same level on window's ID stack as ImGui::BeginPopupModal(). You might want to read a bit on immediate mode UI paradigm in general. Calling ImGui::OpenPopup() from some constructor somewhere hints that you try to use library in a way as if it was retained mode UI (Qt/Gtk/etc). As you noticed immediate mode UIs work quite differently from what you are used to :)

[dumbasaroc]

Sorry that I didn't get back on this sooner, this explanation makes complete sense. I'm going to go with my hacky version for now (until a better solution using my current work presents itself), but I feel that these two messages answer the originally posed question.