Cannot change child window background color via PushStyleColor.

[zwcloud]

Using ImGui v1.50.

For example,

ImGui::PushStyleColor(ImGuiCol_ChildWindowBg, ImColor(255, 0, 0));
ImGui::BeginChildFrame(123, ImVec2(300, 200));
ImGui::EndChildFrame();
ImGui::PopStyleColor();

The result is still a child frame with the default background color. Because the pushed style color is overridden in ImGui::BeginChildFrame:

bool ImGui::BeginChildFrame(ImGuiID id, const ImVec2& size, ImGuiWindowFlags extra_flags)
{
    ImGuiContext& g = *GImGui;
    const ImGuiStyle& style = g.Style;
    ImGui::PushStyleColor(ImGuiCol_ChildWindowBg, style.Colors[ImGuiCol_FrameBg]); //<---Here
    ImGui::PushStyleVar(ImGuiStyleVar_ChildWindowRounding, style.FrameRounding);
    ImGui::PushStyleVar(ImGuiStyleVar_WindowPadding, style.FramePadding);
    return ImGui::BeginChild(id, size, (g.CurrentWindow->Flags & ImGuiWindowFlags_ShowBorders) ? true : false, ImGuiWindowFlags_NoMove | ImGuiWindowFlags_AlwaysUseWindowPadding | extra_flags);
}

That's unexpected. And sure it will also happen when user trying to push ImGuiStyleVar_ChildWindowRounding and ImGuiStyleVar_WindowPadding. I think this is a pitfall of Push/Pop style APIs.

I know we can directly change Colors[ImGuiCol_ChildWindowBg] to set the default background color. But what if one want to set different colors for several child frames?

[ocornut]

Those functions are a little weird. I am working on the styling enums related to borders and background so that may be refactored down the line.

Since you pointed at the code yourself, you can perfectly push the FrameBg color yourself and it'll work tho.

[zwcloud]

Those functions are a little weird. I am working on the styling enums related to borders and background so that may be refactored down the line.

How will you refactor those functions? I want to see them. If that's done please notify me. 🤝

you can perfectly push the FrameBg color yourself and it'll work tho.

Yes, that works.

But I still think there is a pitfall for push/pop style API.

For example, below is a a custom control created by user,

namespace ImGuiEx
{
	void CombinedColorEdit(float* colorA, float* colorB, float* colorC)
	{
		ImGui::PushStyleColor(ImGuiCol_FrameBg, ImColor(200, 0, 0));
		ImGui::ColorEdit3("Color A", (float*)colorA);
		ImGui::PopStyleColor();
		ImGui::PushStyleColor(ImGuiCol_FrameBg, ImColor(0, 200, 0));
		ImGui::ColorEdit3("Color B", colorB);
		ImGui::PopStyleColor();
		ImGui::PushStyleColor(ImGuiCol_FrameBg, ImColor(0, 0, 200));
		ImGui::ColorEdit3("Color C", colorC);
		ImGui::PopStyleColor();
	}
}

Then, someone else want to use it in his project but he want to change ImGuiCol_FrameBg to ImColor(100, 100, 100). So the code he writes is

ImGui::PushStyleColor(ImGuiCol_FrameBg, ImColor(100, 100, 100));
ImGuiEx::CombinedColorEdit(colorA, colorB, colorC);
ImGui::PopStyleColor();

This won't work. Because it will be overriden in ImGuiEx::CombinedColorEdit.

You may say that adding the logic to the parameter of ImGuiEx::CombinedColorEdit can solve the issue. But I think this is a obstacle for reusing code from others.

The example may seems weird but I hope I'm understood. It is really a confusing situation when creating
a custom control composed of existing controls. The last pushed style/color determines the final style/color used by ImGui drawing functions. Is it really a proper way to control styles?

[zwcloud]

And I have more thoughts here. Let's have a look at the famous CSS style system.

The final styles used by web browser is cascaded/inherited according to priority like following:

(from most important to less important)

1. !important Rules

   button
   {
       background-color: blue !important;
   }

2. Inline Styles

   <button style="background-color: red;">ButtonA</button>

3. normal Rules

   button
   {
       background-color: yellow;
   }

4. Default Browser Styles
   built-in styles for button if no style is set

Maybe something like this can be integrated into the Push/Pop APIs or just replace them. Or, introduce some priority mechanism in them.

[zwcloud]

Any suggestions are welcome.
But since this seems beyond the scope of current or possible future implementation, it should be closed.

[ocornut]

Please note that BeginChildFrame() now has been obsoleted in favor of using BeginChild() with the ImGuiChildFlags_FrameStyle flag. See commit cdbc21a.

Those functions were merely PushStyle/PopStyle helpers and custom versions are easy to create.

The removal isn't so much motivated by needing to add the feature in BeginChild(), but by the necessity to avoid BeginChildFrame() signature mismatching BeginChild() newer signature and features.