ofxImGui::Gui::exit() released context, can't Gui::setup() again about ofximgui HOT 2 CLOSED

Hi @Daandelange,
Thanks for your detailed explanation.
Yes, I'm using the code downloaded from code page as zip directly, I might want trying it ASAP at that time.
My design is in one glfw window there is one guimanager and it manages several gui 'pages' in an application.
Because I'm new to Dear ImGui and ofxImGui, I didn't understand the mechanism of them well at first. so I put the instance of ofxImGui::Gui into the 'page' level, and thus it's natural to release and recreate instance of the class each time when switching between 'pages'. So I found the assertion fail.

And after I posted here, as you have mentioned, now I indeed moved the only ofxImGui::Gui instance into my guimanager instance, whose life is as long as the whole application. So the problem is gone for me. I just need to manager the state of some 'controls' which keep alive between 'pages'. It worked well so far.

And thank you for the knowledge you told me. I understand it better.

Best regards.

from ofximgui.

Hi,
From your pieces of code I deduce that you're using the new develop version which brings (beta?) support for multiple instances, I have been working on this feature (and I still need to clean it up before merging it).

First of all, before going further into some details, I'd like to point out that ImGui discourages to use multiple GUI instances and switching them (event with destruct() etc.), and I also remember reading that it's mostly a "design mistake" in the sense that the GUI is meant to be used from within 1 single host system window; we -openFrameworkers- of course can not always comply with this and I tried to come up with a solution for this.

As you pointed out, the solution that I implemented tries to setup 1 ImGui context per ofAppBaseWindow and destroy it on close. In between, you can just render or not, and ofxImGui automatically handles switching the imgui context when you gui.begin()+end() from within each ofAppBaseWindow. The drawback of this solution is that only the first call to setup() from an ofWindow has "master" control over the gui instance, the next ones will setup() as "slaves" and have less control over some settings. (In your ofApp you can check this by checking the return flag of setup().)

So I'd say, what you're trying to achieve is probably already baked in, except that we tested it only for the whole ofWindow lifetime, not for occasional use, but I can understand the need for it. On the other side, I also remember reading advice from the ImGui community that it's recommended (in terms of design principles) to keep that GUI context alive for the whole window lifetime and omit rendering to it if you don't need it and let it "sleep in memory", so we're probably adventuring into unsupported usage of the underlying library.

Do you really wish to kill that instance until its next use ? (Could you use a dummy instance to keep it alive ?)
ImGui has got a very tiny footprint and chances are that you lose more then you gain by periodically destroying/reconstructing it.
What are your application windows lifetimes ?

Btw, it could be great to throw a more informative ofxImGui assert before the ImGui assert throws.

from ofximgui.