Should GImGui in imgui_internal.h be marked with IMGUI_API?

[kylawl]

It seems like that is the intention?

[ocornut]

Not sure what it would mean in term of linkage?

[kylawl]

Without it, we get a link error. With it, we don't.

It seems like that would be the correct thing to do.

[ocornut]

Can you describe your setup? ImGui compiled into a Windows DLL? What crash do you get?

If IMGUI_API is used to fit something such as __declspec( dllimport ) it'll work for the variable but not if IMGUI_API is empty (the variable needs to be declared extern in the .h). So I may need two defines there and I don't know whats a more standard/best practicee

[kylawl]

We include imgui directly into our engine and use your IMGUI_API macro to dll export it for use by other libraries.

Our imconfig.h sets up the defines such that if you are not exporting, you're importing.

Without IMGUI_API on externed global variables, it is not possible to access GImGui from across dll boundaries as the importing project will fail to link.

#ifdef ENGINE_DLL_EXPORTS
    #define IMGUI_API             __declspec(dllexport)
#else
    #define IMGUI_API             __declspec(dllimport)
#endif

[ocornut]

Ok. So I'll probably need internally in imgui.h to use and create a second macro that would default to "extern" whereas IMGUI_API would default to empty token.

[kylawl]

In order to resolve this all I needed to do was change the line to this

extern IMGUI_API ImGuiState* GImGui;

I don't think it needs to be much more than that.

[ocornut]

Oh yeah, I'm so stupid, didn't realize that would work (I don't have a DLL project setup to test). Will do that.

[kylawl]

Super, thanks.

[ocornut]

Done.