Accurate postion of a widget

[miscvariables]

Version: 1.79
Branch: master
OpenGL ES/Android, Native Activity

Operating System: Android

Thank you for the great UI library. I am working on a portable mobile GUI. I have done IME input, inertia scrolling etc, it working perfectly, just like a native app. Except one thing. We all know on mobile screen, either Android or iOS, when app receives input, a soft keyboard will popup, and the ImGui window should resize and scroll the InputText widget to just above the IME region. I need the accurate position of the widget of InputText to adjust the window. I used ImGui::GetFrameHeight()*0.5 for approximate location, the effect is not consistent. I attached 3 captures for indication. enter "Android" in an InputText, when IME popups, resize and scroll the window, under scrolled, exact scrolled, over scrolled.

I read the imgui.cpp and imgui_internal.h and found there is no such a way to get the position of a InputText widget. As I know it's "Immediate Mode GUI", you keep minimal states of widget, and calculate ImRect frame_bb in InputTextEx() and doesn't save it after that, so I can only get the temporary saved state in window->DC using GetItemRectMin() etc. But the states are only available after create the widget. Is it the fact?

I found you saved a g.NavId for long term access, Is it possible to add the position and size(just like frame_bb) of the Active widget. Thanks

[miscvariables]

Update myself.
The suggestion above is not a good solution, because you can't get correct position of multi-line input. After read InputTextEx throughout, I found there was a variable g.PlatformImePos, which is the cursor position in InputText. It's the perfect state for window adjustment. Happy open source!

[ocornut]

It’s an interesting problem, I suppose we would eventually aim to find a way to solve it more elegantly with an interaction between imgui and backends (eg backend notifying dear imgui of on screen keyboard, altering monitor/viewport work area, requesting to keep input source visible). We would probably also need to expose actual input cursor position to be able to handle edge cases of multi-line input frame being larger than available monitor/viewport real estate minus the on screen keyboard.