ImHashStr is internal to ImGui

[lszl84]

Examples use ImHashStr which is defined in imgui_internal.h. Relying on other libraries' internals is generally not recommended, as these internals are not a part of API and can change without notice.

Do we have a better way?

[soufianekhiat]

I know, I discussed with omar about this one. Most of the case you can just use integer and increment them.
I show an illustration of that in im_anim_demo.cpp like:

// Clip IDs
static const ImGuiID CLIP_FADE_IN = 0x1001;
static const ImGuiID CLIP_BOUNCE = 0x1002;
static const ImGuiID CLIP_COLOR_CYCLE = 0x1003;
static const ImGuiID CLIP_COMPLEX = 0x1004;
static const ImGuiID CLIP_DELAYED = 0x1005;
static const ImGuiID CLIP_WITH_CALLBACKS = 0x1006;
static const ImGuiID CLIP_INT_ANIM = 0x1007;
static const ImGuiID CLIP_SEQUENTIAL = 0x1008;
static const ImGuiID CLIP_PARALLEL = 0x1009;
static const ImGuiID CLIP_STAGGER = 0x100A;

[ocornut]

I think it’s fine for extensions to use internals. It’ll just be the job of the extensions to catchup and use eg ‘#if IMGUI_VERSIOn_NUM > XXXXX’ statements to support changes if they happens. But those hashing functions have been fairly stable.

[lszl84]

I think it’s fine for extensions to use internals.

Still, I was talking about example code, i.e. client code.

Maybe I am traumatized by years of iOS development, where Apple would reject your app from the store if you used their private APIs ;) But I do think that using library's internal functions from the client code (not extension's internal code) is a bad practice.

[ocornut]

Oh I agree user code shouldn’t promote it too much. Essentially using ImGui::GetID() would do the same w/ id stack, or ImAnim could expose a simple helper that calls ImHashStr()

[soufianekhiat]

I will add an ImAnim::GetUniqueID() and ImAnim::GetFrameID(), but I'll keep the imgui_internal.h until the next major release.