I just noticed a weird (new?) behaviour which I didn't notice when I started using the imgui_memory_editor:

When I'm clicking a number to start editing, and the click takes a bit longer, the focus isn't taken, so editing doesn't start. Only when "short-tapping" through a touchpad it seems to work.

I had to replace the IsMouseClicked(0) here:

https://github.com/ocornut/imgui_club/blob/e680ad8d6b9278367d0f71a698beb96b70762ed4/imgui_memory_editor/imgui_memory_editor.h#L394

...with IsMouseReleased(0). This always seems to work, both with "short taps" and "long clicks", but I don't understand why.

Is anybody else seeing this too? Could this be caused by a change of behaviour in newer ImGui versions?

I found it a bit hard to tell exactly (I always find this input-type stuff difficult to debug...) but it looks like clicking on the hex area was being interpreted as an attempt to move the window. The move then deactivated the text box used for user input, which caused the input to be canceled.

Making the child window non-moveable fixes this, but it's possible there's some better way of doing it, e.g., by having the hex view swallow the click or something.

Thanks,

--Tom

This change allows the addition of additional memory content previews at the bottom of the memory editor. I'm using it to show a sparkline at the moment but it's general and allows anything to be added.

The settings and data visualisation footers take a lot of precious screen space. I prefer to implement my own GUI for this, because I know the best representation for my data, so in this PR I suggest an option to hide the settings footer.

This pull request adds a second line to the bottom of the memory editor window. It allows to show the currently selected byte in various representations, like uint8, in octal and big endian. The current available types are:

• int8
• uint8
• int16
• uint16
• int32
• uint32
• int64
• uint64
• float
• double

Each of these types can be loaded from memory as little or big endian. They can be viewed in either:

• binary
• octal
• decimal
• hexadecimal

The editor will read from the following bytes, if possible, if no bytes are available, they result will be truncated. Nothing will be calculated if the editor is readonly.

As of right now the implementation is a bit ugly and wordy, I'm open to any suggestions to improve it. A small gif showing it in action can be seen here: https://twitter.com/ArvidGerstmann/status/898283352771497984

Using the sample code given to recreate the issue. Then set the values to below 15 both data and size with enabled option data preview, will cause the crash when key pressed down arrow.

// Sample 12
static char data[12];
size_t data_size = 12;
// and
mem_edit_1.OptShowDataPreview = true

This was due to the function of DrawPreviewData(), the reason was due to the mem_size is greater than the addr. The partial fix I did at the very first line of the function is to set the max memory size of the address(highlight selected): if (addr > mem_size) addr = mem_size;

Currently, imgui_memory_editor uses _snprintf when compiling with MSVC, and snprintf otherwise. These two functions are similar, but they have slightly different behavior:

The snprintf function and the _snprintf family of functions format and store count or fewer characters in buffer. The snprintf function always stores a terminating null character, truncating the output if necessary. The _snprintf family of functions only appends a terminating null character if the formatted string length is strictly less than count characters.

(From https://docs.microsoft.com/en-us/cpp/c-runtime-library/reference/snprintf-snprintf-snprintf-l-snwprintf-snwprintf-l)

This change unifies the calls across different compilers. It also silences MSVC warnings about using the "unsafe" versions of the stdio functions sprintf and sscanf. Microsoft provides "safe" versions of these functions, but they are not part of the C standard and therefore not portable.

Changed return value to bool to detect if editor is open. Window height is now set to half of window width so that editor is approximately the right size on default creation.

Hi,

I'm trying to compile imgui_freetype with dear_imgui version 1.51 but I'm getting a few errors. One of which indicates that ImFontAtlasBuildRegisterDefaultCustomRects(atlas) could not be found which lets me believe this function existed in a previous version of dear_imgui but I might be wrong as I don't see any mention of it in API changelog. The other errors are the same but for other variables or function calls. I was just wondering if I was missing something obvious. If my issue isn't clear enough please let me know.

Thanks in advance for your help

The dot character ('.') is a valid, printable character, but was being inadvertently drawn as greyed out in the memory editor's ascii display. This has been fixed.

A user can double-click the Columns DragInt and can set Cols outside the (4, 32) range. Setting Cols to 0 (or less) is pathological and causes a divide-by-zero later.

Suggest this fix

                if (ImGui::DragInt("##cols", &Cols, 0.2f, 4, 32, "%d cols")) 
                { 
                    if (Cols <= 0) Cols = 1; // Crashproofing
                    ContentsWidthChanged = true; 
                }

When using the UCRT64 environment of MSYS2 to make a build that links to the UCRT, instead of to the old msvcrt, stdio and snprintf() work the way they do in MSVC, and expects the same modifiers. However, _MSC_VER is not defined in the UCRT64 headers, and thus the current guard doesn't work. Checking for _UCRT, which is defined, fixes this. Without this fix, it is necessary to define __USE_MINGW_ANSI_STDIO at compile time so as to switch to its implementation of stdio, or compilation will fail if you set warning flags on (-Wall, -Werror, etc). One could ofc ignore this warning but that seems like a bad plan...

Build error log

BgColorFn works just like HighlightFn, except it allows coloring all bytes in view instead of just the highlighted bytes. The return value is the color; 0 means don't change the color. HighlightFn takes priority over BgColorFn.

InteractFn can be used to display popups, context menus, etc.

From @simuuz https://github.com/ocornut/imgui/issues/3488#issuecomment-720126520

The reason for me making it from scratch is that the memory watcher extension for ImGui dies when feeding him with address spaces that are larger than 24 bit (IIRC, at least that's what has happened to me and some other emulator developers), and since the GBA has an address space that ranges from 28 to 32 bit, here I am :3

I answered

I haven't tried but I am assuming that there'll be an issue with floating point precision with large scroll amount. I don't know how you'd intend to solve it but whatever the solution (maybe implementing custom scroll bar + virtualizing position) it would be worth implementing it in the existing memory editor.. (let's resume this discussion in imgui_club issue tracker)