Font for Window Title

[hippyau]

Hi!
I am having a problem with setting a font for the window title. If I...

// this is PureBasic, not C/C++, but same principle
PushFont(*MyFont);
Begin("Example Bug");
PopFont();
End();

If compile with debugging it fails with an assertion on PushFont that there is a "PushFont/PopFont Mistmatch", whereas if I compile using release, it seems to work fine (obviously not asserting)... but i'm worried that is not okay and maybe there is a stack growing somewhere?

Is this even the correct way to select a font for the window title?

Cheers,
Hippy

[hippyau]

Here is a screenshot...

Cheers,
Hippy

[ocornut]

Hello @hippyau,

This is the right way to change the title bar. The assert comes from an issue / limitation with the stack checker because it compares stack size at the boundaries of window Begin/End. It's been a little annoying in several other situations, would like to improve it without completely removing it.

At the moment the correct workaround would be to do:

ImFont* font = GetFont();
PushFont(title_bar_font);
Begin(...)
PushFont(font);
...
PopFont()
End();
PopFont();

This is strictly due to this stack checker being a little in the way. I think as we work on #1651 we could make this extraneous push/pop not required.

(PS: If you post assertions in a bug report, generally try to post the full callstack, instead of just a dialog box. You can press Retry to open the debugger)

[hippyau]

Um, you answered in less than ten minutes! I'm sending you a donation 😁

Thanks so much, and i'm unable (don't know how) to debug this properly because I'm calling a DLL from another language in which i'm debugging my app with it's own debugger that can't handle the DLL debugging nicely.

Thanks so much for the work around, I kind thought that might work, but I didn't want to specify the inner font.... your workaround is ideal! of course, just get the default font!

Cheers,
Hippy

[ocornut]

Thank you Hippy. It's an annoyance that has been on my mind for a while, people more frequently have this issue with PushStyleColor or PushStyleVar. The problem is that if we don't catch the underflow at the right time in the window stack it becomes tricky to provide a meaningful report.

Perhaps for the color, style and font stacks we should change the test from == to >=.

-    { int current = g.ColorModifiers.Size;      if (write) *p_backup = current; else IM_ASSERT(*p_backup == current && "PushStyleColor/PopStyleColor Mismatch!");       p_backup++; }    // Too few or too many PopStyleColor()
-    { int current = g.StyleModifiers.Size;      if (write) *p_backup = current; else IM_ASSERT(*p_backup == current && "PushStyleVar/PopStyleVar Mismatch!");           p_backup++; }    // Too few or too many PopStyleVar()
-    { int current = g.FontStack.Size;           if (write) *p_backup = current; else IM_ASSERT(*p_backup == current && "PushFont/PopFont Mismatch!");                   p_backup++; }    // Too few or too many PopFont()
+    { int current = g.ColorModifiers.Size;      if (write) *p_backup = current; else IM_ASSERT(*p_backup >= current && "PushStyleColor/PopStyleColor Mismatch!");       p_backup++; }    // Too few or too many PopStyleColor()
+    { int current = g.StyleModifiers.Size;      if (write) *p_backup = current; else IM_ASSERT(*p_backup >= current && "PushStyleVar/PopStyleVar Mismatch!");           p_backup++; }    // Too few or too many PopStyleVar()
+    { int current = g.FontStack.Size;           if (write) *p_backup = current; else IM_ASSERT(*p_backup >= current && "PushFont/PopFont Mismatch!");                   p_backup++; }    // Too few or too many PopFont()

So this becomes ok:

ImGui::PushStyleColor(ImGuiCol_Text, ImVec4(1, 0, 0, 1));
ImGui::Begin("Test #1767 - OK");
ImGui::PopStyleColor();
ImGui::End();

But this would still assert:

ImGui::Begin("Test #1767 - KO");
ImGui::PushStyleColor(ImGuiCol_Text, ImVec4(1,0,0,1));
ImGui::End();

[hippyau]

You're welcome. Love your work :)

Not being the best a this.... because it's not asserting in release mode compile, is this just an annoyance, or am I leaking memory? (does this reset every frame?) It seems to work fine in release, but i've now tried a window with another level of fonts nested inside with the workaround and now it's asserting there.

Will I get away with it? :)

[ocornut]

You are never leaking memory, that's for sure, but this is trying to warn you of incorrect use cases. In the use case you mentioned above, the assert is a false positive that we can fix with the change discussed above.

i've now tried a window with another level of fonts nested inside with the workaround and now it's asserting there.

There's no reason it should assert using the PushFont/Begin/PushFont/../PopFont/End/PopFont scheme, you have another issue in there.

[hippyau]

Awesome, thanks for your time! (fixed my nest, popped to much)

[ocornut]

Applied this long desired change, closing this issue.