mirror of
https://github.com/ocornut/imgui.git
synced 2026-11-14 19:04:44 +00:00
IsItemActive() always return false after calling InputFloat() #840
Labels
No labels
accidentally closed
android
backends
bug
building
clipper
coloredit
color spaces
cplusplus
data types
demo
disabled
doc
docking
dpi
drag drop
drawing/drawlist
dropped
dx12
enhancement
focus
font/text
gallery
help wanted
idle/power saving
ime
in progress
inputs
inputtext
internals
label/id and id stack
language bindings
layout
linux/bsd
menus
multi-contexts
multi-threading
multi-viewports
nav
news/info
opengl
optimization
osx/ios
overlap
plot/graph
popups
question
scrolling
selection
settings
sliders/drags
style
tables/columns
tabs
test wanted
tools
tooltips
tree
tricks & tips
useful widgets
vulkan
web
window pos/depth
window sizing
No milestone
No assignees
1 participant
Notifications
Due date
No due date set.
Dependencies
No dependencies set.
Reference
ocornut/imgui#840
Loading…
Add table
Add a link
Reference in a new issue
No description provided.
Delete branch "%!s()"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
IsItemActive()always returnfalseafter callingImGui::InputFloat(...).InputFloatis implemented usingInputScalerExwhich wrapsInputTextin group. EndGroup() modifywindow->DC.LastItemIdand ing.ActiveId == window->DC.LastItemIdinIsItemActive()is always false.Is this a real issue or expected behavior?
Definitively a bug, needs to be fixed!
This is possible workaround. But
IsItemActiveseems to lag a frame.I don't see any reason for a lag there. IsItemActive() will test those values directly. Did you confirm the lag?
However this need a little adjustment/work-around to also function when the Steps buttons are enabled.
I have applied the more general fix where if any item within the group is the active id, then IsItemActive() after EndGroup() will report true. This fix similar issue for other widgets using BeginGroup(), and allow removal of similar workaround code in InputTextMultiline().
Repro
The lag is a different issue, if you are talking about
Looking into that.
Fixed the other issue.
@ocornut Thank you!