VL.ImGui: Text (Multiline) ignores text position

I am using the Text (Multiline) ImGui widget to display some text over multiple lines.

You can set the width of the text, which internally sets the text wrap position. This works fine until you position the text somewhere else using SetCursorPosition.

It should first get the cursor position and then add the width to the wrap position it sets. Then it works correctly.

Like so:

As it is currently when you offset the text horizontally using SetCursorPosition, the width needs to be increased, but it then breaks the position once you resize the window.

Thanks for fixing!

I have attached a demo patch showing the crux of it. Normally it would be fine to just set the position, but the position might be dependent on something like the width of the container, which changes if you resize the window.

imgui-text-multiline-bug

imgui-text-multiline-bug.vl (14.8 KB)

2 Likes

It looks like SetWrapTextPosition should respond to SetCursorPosition?

In imgui this is done with PushTextWrapPos() and PopTextWrapPos().

Honestly, it may be counterintuitive, but it’s probably the right way to do it, and no fix is needed. At least I haven’t seen any other way in the imgui documentation.

Good question, should this be put in the node straight away? Probably yes. But it will look a bit bulky: get the current cursor, add the width and pass it to the position for wrapping.

I think it would be fine to leave it as it is, but to just rename the Width input to “Wrap Position”. Then it’s clear what it does and that if we set the cursor position we have to add the x offset to the wrap position. Calling it “Width” only works if it is at the default position.

If you look inside you can see that the input should be called Position anyways. If it’s called “Width”, then it should correctly take the starting position and add it to the Width to set the new position.

1 Like

I think the Imgui wrapper code was written in large chunks at once. The nuances of meaning in such work can be lost simply because the wrapper authors themselves didn’t know exactly how it worked. There are a lot of non-obvious decisions in imgui in favour of performance.

Yeah, I totally get it. It’s not immediately obvious. But that’s why we have these reports, so the library can get better incrementally.

1 Like

Hello,

yes, it’s true, the pin name is misleading and should be fixed.
As a general workflow I would suggest to put the Text (Multiline) into the ChildWindow. And position the ChildWindow with the SetCursorPosition. Then the Width of the Text (Multiline) can stay 0, filling the whole ChildWindow. And the ChildWindow’s Size can be set to any value you like, incl < 0 (remaining space minus value).

Best,
Anton

3 Likes