Feature Request: Allow storing user data inside windows and to imgui.ini file

[almic]

I could not find this already, so I'm sorry if this is duplicating another issue.

What this means:
Provide a way to store custom data structures inside the window objects themselves, which are already publicly available through the imgui context in Windows. In short, this will let programmers access data about windows without abstracting their own wrapping class.

Why this is better than using a wrapping class:
For my current use case, I would like to initialize a window with additional data that can change at start-up and during run-time. It is possible to create a wrapper that saves a pointer or ID for the window along with the additional data, but this now means I would have to also track the windows and effectively rewrite the current implementation for saving window information to the imgui.ini file. Instead, it would be easier to allow developers to save (or serialize) custom data structures for the windows which is already saved by dear imgui.

Why this is better than hard-coding everything into dear imgui:
It would obviously be a lot of work to do things like storing the state of every widget inside a window, simply due to the fact that saving the layout of each window alone would bloat the .ini file and create a lot of unnecessary double-checking during window drawing. Letting the developer choose what data to save for a window and where it should go is easier for everyone.

What this could look like:
First, here is how it looks in use, I explain it afterwards and show what code changes might be needed to allow this.

MyClass.h

#include <imgui.h>
class MyClass : public ImGuiWindowClass
{
public:
    int special_integer;
    char some_user_inputs[100];

    MyClass()
        : ImGuiWindowClass()
    {
    }

    virtual void Save(ImGuiTextBuffer* buf) override
    {
        buf->appendf("SpecialInt=%d\n", special_integer);
        buf->appendf("UserInput=%s\n", some_user_inputs);
    }

    virtual void Load(const char* line) override
    {
        int i;
        char cstr[100];

        if (sscanf(line, "SpecialInt=%d", &i) == 1)
        {
            special_integer = i;
        }
        else if (sscanf(line, "UserInput=%[^\n\r]", cstr) == 1)
        {
            some_user_inputs = cstr;
        }
    }
}

main.cpp

// Before the render loop...
bool show_window = true;
MyClass* userDataWindowClass = new MyClass();
char* userString = userDataWindowClass->some_user_inputs;
int* userInteger = &userDataWindowClass->special_integer;

// Somewhere inside the render loop...
ImGui::SetNextWindowClass(userDataWindowClass);
ImGui::Begin("My User Data Window", &show_window, 0);

ImGui::InputText("Some Option", userString, IM_ARRAYSIZE(userString));
ImGui::SliderInt("Pick a number", userInt, 10, 100);

Sorry if this code has bugs, I just wrote it manually inside the issue box and didn't actually test it. This is just to give you an idea of how it can be used.

How it could work:
I'm not as familiar with the code base, but from initial scanning it seems like there wouldn't be very many changes needed to support this.

The functions Save and Load would need to be added as virtual functions to the ImGuiWindowClass class/ struct. As well, a pointer like ImGuiWindowClass* WindowClass would have to be added to the ImGuiWindowSettings struct.

Inside the current SettingsHandlerWindow_WriteAll function that is responsible for building the imgui.ini file, all that would need to be added is a call to settings->WindowClass->Save(buf). This might need a new buffer for the call specifically, and could only be added if the buffer actually contains data. This would probably best be added last using a header similar to [Window] maybe something like [UserData], of which is considered finished loading custom data when the next [Window] line appears.

Then inside the SettingsHandlerWindow_ReadLine function you'd add a entry_data->Load(line) function call, which is only called when something like [UserData] is found and a switch is flipped.

From what I can see, this is all that really needs to be done. Like I wrote earlier, this is all already possible to do, but it requires us developers to reinvent the wheel so-to-speak and we'd end up having the imgui.ini file as well as our own .ini-like file. This way, we can simply add our data to a derived class which dear imgui will automatically save and load for us.

I would love to see this implemented! If you give me the green light I'd happily create a pull request to add this 🙂

[ocornut]

(reposted with missing code blurb)

Hello,

This would probably best be added last using a header similar to [Window] maybe something like [UserData], of which is considered finished loading custom data when the next [Window] line appears.

Yes you can do that.

I am not sure to understand why you don't just add a new .ini handler in the g.SettingsHandlers this is what it is for.

You can maintain your own key>value store where value is MyStruct and make that persist in the .ini file this way. The boilerplate needed is quite small, there's no reason to store your value in the same .ini block as the one imgui uses for its stuff.

Just copy what ImGui::Initialize() does and add your own handler with a TypeName of UserData.

// Add .ini handle for UserData type
ImGuiSettingsHandler ini_handler;
ini_handler.TypeName = "UserData";
ini_handler.TypeHash = ImHashStr("UserData");
ini_handler.ReadOpenFn = MyUserData_ReadOpen;
ini_handler.ReadLineFn = MyUserData_ReadLine;
ini_handler.WriteAllFn = MyUserData_WriteAll;
ImGui::AddSettingsHandler(&ini_handler);

You can store and write the same title, so your .ini file would look like:

[Window][Hello, world!]
Pos=0,19
Size=1264,366
Collapsed=0

[Window][ImGui Demo]
Pos=0,421
Size=1264,340
Collapsed=0

[UserData][Hello, world!]
UserInteger=1

[UserData][ImGui Demo]
UserInteger=1

(Linking to #437)

[almic]

Okay, I see now. I'm hesitant to do this though which is why I would suggest giving "dedicated support" for this type of stuff. Mostly because if the system ever changes, even just slightly, then I may have to rewrite the implementation. But if this is what you recommend, then I'll do it.

[ocornut]

From my point of view I need to avoid taking too much unnecessary responsability and that means not providing too many guarantees. This is what imgui_internal.h is for. If I start providing guarantees (as with anything in imgui.h) I have to care and maintain those features forever while trying to not break them and I am already swamped in work.

[slajerek]

I wonder what is the proper way now of extending ImGuiWindow with user data? I am doing now by manually patching sources by adding at the end of ImGuiWindow definition in imgui_internal.h

	// any user data assigned to this ImGuiWindow
	void *UserData;

I need the userData to extend some window features which are not yet available in ImGui. Thanks in advance.

[thedmd]

There is currently no direct way to extend ImGuiWindow, but you can use hooks to extend ImGuiContext.

What I did is I defined two structures:

• ImGuiLayoutWindowState - extra state associated with ImGuiWindows
• ImGuiLayoutState - extra state associated with ImGuiContext, hold list of ImGuiLayoutWindowState

Then I ended up with:

static ImGuiLayoutWindowState* GetCurrentWindowLayoutState();

(https://github.com/thedmd/imgui/blob/827eb6306d4d54b3190a24de495c995359eb9005/imgui_stacklayout.cpp#L333)

Basically what the function does is:

• get or create ImGuiLayoutState for current ImGuiContext
• get or create ImGuiLayoutWindowState for current ImGuiWindow (via ID)

ImGuiLayoutState use ImGuiContextHook to cleanup after itself when context is destroyed or to react to NewFrame/EndFrame. There are also some extra events available too you may find interesting for your use case.

ImGuiLayoutState use context hooks for cleanup and to sync with NewFrame/EndFrame. You can attach to events you care about.

Ideally there should be a way to re-parse ini file to extenstion activated after new ImGuiSettingsHandler is registered., so your extension will load their state as expected. So far it is not a thing, so be prepared for making workarounds.
Note: You will get ini data if your ImGuiSettingsHandler is installed before ImGuiContext is created.

This is the current state afaik.

[moebiussurfing]

Hello,
there is some easy workaround to include the Tree states (collapse) into the .ini settings file?
To make the state persistent as the Windows are.