Can only add events to current context. #6199
Labels
Comments
|
We should probably lift that constraint by storing a context pointer in IO. Would also be desirable for #5856 |
ocornut
pushed a commit
that referenced
this issue
Mar 8, 2023
…6199): ImGuiIO This commit is a preparation toward adding ImGui apis with explicit context and making ImGui applications being able to use multiple context at the same time whatever their concurrency model. About ImGuiIO: - ImGuiIO depends on ImGuiContext because some of its method want to event to `g.InputEventQueue`. - To make ImGuiIO aware of the context to use, context which creates the ImGuiIO is given as argument of ImGuiIO constructor. - The assert `IM_ASSERT(&g.IO == this && "Can only add events to current context.")` has been removed since it does not make sense anymore NOTE: ImGuiIO could be completely independent of ImGuiContext if the InputEventQueue was moved from ImGuiContext to ImGuiIO, but since ImGuiIO is a public class it would expose InputEvent type. Solving this problem is out of the current scope, but it is interesting to notice.
|
Fixed with 10ace22 by @Dragnalith |
ocornut
pushed a commit
that referenced
this issue
Mar 8, 2023
…: ImGuiWindow, ImGuiInputTextCallbackData, ImGuiListClipper, ImGuiStackSizes This commit is a preparation toward adding ImGui apis with explicit context and making ImGui applications being able to use multiple context at the same time whatever their concurrency model. This commit modifies ImGuiInputTextCallback, ImGuiListClipper and ImGuiStackSize so those classes do not to depend on GImGui context anymore. About ImGuiInputTextCallback: - ImGuiInputTextCallback depends on ImGuiContext because it has a `InsertChars` method adding character to `g.InputTextState` - To make ImGuiInputTextCallback aware of which context to use, the appropriate context is given as argument of ImGuiInputTextCallback constructor. About ImGuiListClipper: - ImGuiListClipper apply to a context through its `Begin`, `End`, and `Step` method. - To make ImGuiListClipper aware of which context to use, the appropriate context is given as argument of ImGuiListClipper constructor. - Since the behavior is different than previously the class has been renamed ImGuiListClipperEx - In order to preserve backward compatibility, a subclass of ImGuiListClipperEx named ImGuiListClipper has been defined and forward the implicit context to ImGuiListClipperEx parent. About ImGuiTextFilter: - ImGuiTextFilter depends on the implicit context because the Draw(..) method call ImGui::InputText(...) - Instead from that commit the Draw(...) method takes an explicit context as first argument - Since the behavior is different than previously the class has been renamed ImGuiTextFilterEx - In order to preserve backward compatibility, a subclass of ImGuiTextFilterEx named ImGuiTextFilter has been defined. This subclass has a draw method override which and forward the implicit context to the parent class Draw(...) About ImGuiStackSizes: - ImGuiStackSizes was depending on ImGuiContext because of its `SetToCurrentState` and `CompareWithCurrentState` method - ImGuiStackSizes is an helper object use for comparing state of context. It does not necessarily need to compare the same context. For that reason, as opposed to previous classes it takes the context it wants to compare to as argument of its method. - For this occasion `SetToCurrentState` and `CompareWithCurrentState` have been renamed `SetToContextState` and `CompareWithContextState` to match the new method signature. ImGuiListClipper ImGuiInputTextCallbackData
ocornut
pushed a commit
that referenced
this issue
Mar 8, 2023
…: ImGuiWindow, ImGuiInputTextCallbackData, ImGuiListClipper, ImGuiStackSizes This commit is a preparation toward adding ImGui apis with explicit context and making ImGui applications being able to use multiple context at the same time whatever their concurrency model. This commit modifies ImGuiInputTextCallback, ImGuiListClipper and ImGuiStackSize so those classes do not to depend on GImGui context anymore. About ImGuiInputTextCallback: - ImGuiInputTextCallback depends on ImGuiContext because it has a `InsertChars` method adding character to `g.InputTextState` - To make ImGuiInputTextCallback aware of which context to use, the appropriate context is given as argument of ImGuiInputTextCallback constructor. About ImGuiListClipper: - ImGuiListClipper apply to a context through its `Begin`, `End`, and `Step` method. - To make ImGuiListClipper aware of which context to use, the appropriate context is given as argument of ImGuiListClipper constructor. - Since the behavior is different than previously the class has been renamed ImGuiListClipperEx - In order to preserve backward compatibility, a subclass of ImGuiListClipperEx named ImGuiListClipper has been defined and forward the implicit context to ImGuiListClipperEx parent. About ImGuiTextFilter: - ImGuiTextFilter depends on the implicit context because the Draw(..) method call ImGui::InputText(...) - Instead from that commit the Draw(...) method takes an explicit context as first argument - Since the behavior is different than previously the class has been renamed ImGuiTextFilterEx - In order to preserve backward compatibility, a subclass of ImGuiTextFilterEx named ImGuiTextFilter has been defined. This subclass has a draw method override which and forward the implicit context to the parent class Draw(...) About ImGuiStackSizes: - ImGuiStackSizes was depending on ImGuiContext because of its `SetToCurrentState` and `CompareWithCurrentState` method - ImGuiStackSizes is an helper object use for comparing state of context. It does not necessarily need to compare the same context. For that reason, as opposed to previous classes it takes the context it wants to compare to as argument of its method. - For this occasion `SetToCurrentState` and `CompareWithCurrentState` have been renamed `SetToContextState` and `CompareWithContextState` to match the new method signature. ImGuiListClipper ImGuiInputTextCallbackData
ocornut
added a commit
that referenced
this issue
Mar 21, 2023
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Version/Branch of Dear ImGui:
Version: 1.89.3 WIP (18923)
Branch: docking
Back-end/Renderer/Compiler/OS
Back-ends: glfw / erhe
Operating System: Windows 10
My Issue/Question:
I am adding file dialog usage into my code. The code that uses the file dialog is like this:
My
select_file()uses WindowsIFileOpenDialogwhich opens a new window on top of my glfw window. This triggers glfw focus callback event, which is happening in context that is something else than the main thread.I am not sure how to deal with the glfw focus event. I would like to call
m_imgui_context->IO.AddFocusEvent(focused != 0)(for my Window ImGui viewport). However, current ImGui does not allow this, if I happen to be using in different ImGui context.I wonder what my options are:
GImGuithread_localmight allow me to have a different ImGui context in the wndproc context?Can only add events to current contextrestriction?I'd really prefer removing the restriction on requiring context to be current in order to be able to send events to it. Any thoughts? Thanks!
The text was updated successfully, but these errors were encountered: