InputText, InputInt, InputFloat: add ImGuiInputTextFlags_NoLiveEdit flag

[ocornut]

ImGuiInputTextFlags_NoLiveEdit (tentative name) would only apply the value when pressing Return or intentionally changing focus via Tab, as opposed to the current behaviour of applying the value as it is being edited. How about when unintentionally losing focus?

(ref. #700)

[Cthutu]

That's ok. That's how windows and OS X handles it
On Thu, Jun 16, 2016 at 16:14, omar notifications@github.com wrote:

ImGuiInputTextFlags_NoLiveEdit (tentative name) would only apply the
value when pressing Return or intentionally changing focus via Tab, as
opposed to the current behaviour of applying the value as it is being
edited. How about when unintentionally losing focus?

(ref. #700 #700)

—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
#701, or mute the thread
https://github.com/notifications/unsubscribe/AAVRxqolsk47I99TmR3Z1JuP55sWPUtkks5qMa6qgaJpZM4I3w-k
.

[ocornut]

Setting the xyz values of an object is something you don't live update on,
otherwise the object will be jumping about as you type :)

I think live update makes more sense for string/text values than for float/int.
I am considering changing the default so that for float/int it wouldn't live update by default. Will poll people on twitter for that.

[ocornut]

FYI started working on this but it is hard to accomplish 100% in an imgui context.
We can only write back within the InputXXX call so it means the function needs to tell that it is being stolen focus. While it is feasible to cover the most common case (such as tabbing, or explicitly clicking outside) some other cases are harder (any code explicitly stealing ActiveId would be a problem, or user stopping to render the widget/window would allow lose the data but that is less of a problem). Looking into it.

[Cthutu]

I don't think you should have different defaults depending on the type of values (string or float etc). I think it should be consistent in the API. Maybe make live editing not the default and add a ImGuiTextEditFlags_LiveEdit?

[ocornut]

Putting this on hold until I do a big cleanup to add UTF-8 to stb_textedit and ditch the back and forth conversions. The code before the is too risky and bug-prone.

Basically we need to store the data so that when another text widget submitted earlier steals focus and starts editing, the old data is still available for the next recently-been-editing widget to apply back to the user variable. So that means likely we'll need to have two text buffers in memory and alternate their use to avoid extra copying of data. Currently InputText() is too complex because of how it has to work-around limitation of stb_textedit while staying efficient for large text, so I am going to fix that first (not a big big change).

[drudru]

👍
Ran into this as well for a property editor. I was able to work around it.
However, wanted to chime so I can stay up to date on this topic.

[damqui]

same here also for a property editor. what was your work around ? using intermediate buffer with live edit + copying into edited value when focus lost / tab / enter ?