Multi Host Windows on DirectX11/Win32

[Bit00009]

Version/Branch of Dear ImGui:

Version: 17803
Branch: master

Back-end/Renderer/Compiler/OS

Back-ends: imgui_impl_dx11.cpp + imgui_impl_win32.cpp
Compiler: VC++ 2019
Operating System: Windows 10 latest version

My Issue/Question:
I'm trying to bring imgui to my plugin for a win32 based application. I want to use multiple windows using imgui ui...
I'm aware of docking branch but this is not what I need I guess because it needs a main viewport but I don't have any and I just have toolbars and several tool windows.
I could successfully create two imgui windows but there's hitting problem and some extra issues.
Is there any solution or way to make this work in a simpler way?

Here's the source code of my project, it's clean and minimal :
https://github.com/Bit00009/imGUIWin

Regards,
Ultran

[ocornut]

I am not sure I understand your problem very well, but it could be the same as #3350

Doesn’t the application you are creating a plugin for already has a decorated window? This could serve as the main host window.

(I suggest reading the Glossary section in wiki to ensure you are referring to the right terminology, as those advanced multi-viewports discussions can easily get confusing.

I could successfully create two imgui windows but there's hitting problem and some extra issues.

I am afraid it’s not enough to say that. Please clarify what you tried, what problem you ran into etc otherwise I can only assume you are submitting a “XY problem” (http://xyproblem.info). From the description of your problem I don’t quite understand why you cannot use multi-viewports feature.

[Bit00009]

Thanks for reply,
I uploaded source to avoid XY porblem, This is how I do my approach :

• I created a class contains window handle, swapchain and RTV [ Here ]
• I create one global DX11 device [ Here ]
• I create swapchain and context in Create function of each imGUI wndow class [ Here ]
• Now each class is getting rendered manually in dispatching message using its rendering function [ Here ]
• Here's rendering calls [ Here ]

Now two windows are getting rendered just fine, I tested different UIs as well and they are rendered fine.
The issue is communicating and IO
If I switch to new imGUI context using SetCurrentContext app will crash on some unexpected error or sometimes GetFont

What I need should be super simple but I can't find the solution.

I can't use docking because my main application is Maya and I don't want to manipulate it's main window because it leads to random crashes.
The way I want to use imGUI in my plugin is I create maya child window and host my directx window inside it.
I hope this information will be enough.

Also I may need to create my plugin as seperated proess with no main window so I need only different tool windows with imGUI ui, I'm currently using WPF for my user interfaces but imGUI is a way better than it so I really like to use it.

I did read Glossary and also tried most of issues on imGUI github but still can't figure it out.

Thanks

[Bit00009]

@ocornut I did take a deep look at docking source, as far I understood imgui uses independent swapchain and rtv for each viewport so why there always should be a mother window? I removed mother window swapchain and rtv and disabled ShowWindow and UpdateWindow and also ImGui::Render and child windows are working fine so what is involved from mother window to them and is it possible to remove mother window and just deal with child windows?

[ocornut]

One of the issue is that there's various code relying on the MainViewport, and we'd need to provide the option to get rid of this dependency. This include providing a high-level helper to get a safe "origin" point so instead of user using GetMainViewport()->Pos as a default reference for traditional apps they'd use a function which would e.g. return data for default viewport OR default monitor.

[Bit00009]

One of the issue is that there's various code relying on the MainViewport, and we'd need to provide the option to get rid of this dependency. This include providing a high-level helper to get a safe "origin" point so instead of user using GetMainViewport()->Pos as a default reference for traditional apps they'd use a function which would e.g. return data for default viewport OR default monitor.

Are you planning to make this changes?

[ocornut]

Yes eventually but its not a high priority at the moment.