-
-
Notifications
You must be signed in to change notification settings - Fork 10.3k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
direct way to check which inputs ImGui wants to capture #364
Comments
You can probably employ a scheme of just always giving mouse position to ImGui and query the WantInput* fields before calling NewFrame(). You'll have a 1 frame delay because transitioning states but it probably won't matter. You are right that this system should be improved but that workaround may be good enough (and it is way way too complex). |
I'm keeping this idea in mind but I think there is a viable-enough way of getting around it. You can either choose to have a one-frame delay in the handling of WantInput* (not that you inputs themselves won't have a one frame delay, only reacting to the transition between !Want and Want), either store your inputs, or just pass them to your application and cancel them afterward, there's various ways of handling it. |
As far as I understand, the current way to do this is:
Depending on what inputs an app receives, the process of queuing and dequeuing these events can be pretty complicated and it makes ImGui difficult to integrate in some engines. For example, I recently used ImGui in an application which used the WM_POINTER family of messages, and these messages have large transient side-state associated with them (see GetPointerInfo etc) which disappears when WNDPROC returns. Queuing/Dequeuing these was a real mess, and necessarily implies the integration will be more intrusive because the magic functions like GetPointerInfo can't be used as-is.
Instead, it would be great if ImGui had some functions to compute WantCaptureKeyboard, WantCaptureMouse, WantTextInput, based on input received so far. This would allow an app to decide right away when an input is received whether to pass it to the app or not.
I'm not sure if this is possible for every case given the nature of immediate mode, but an approximation would be pretty nice. I have a hacky proof of concept of this for you to consider (below). The idea is that you can just put
at the top of your WNDPROC and be done.
The text was updated successfully, but these errors were encountered: