Preventing horizontal scroll

[pixtur]

Version/Branch of Dear ImGui:

Version: 1.70
Branch: master

Back-end/Renderer/Compiler/OS

Back-ends: imgui.net
Compiler: c#/.net
Operating System: win10

My Issue/Question:
I have some windows that don't need horizontal scrolling. Although I can disable the display of the scrollbar, I haven't found an option to prevent the horizontal scrolling to take effect when accidentally pressing the horizontal mouse wheel or scrolling on a touch pad.

Is there something I can do to prevent scrolling besides not passing along the horizontal scroll wheel data?

Screenshots/Video

[ocornut]

Hello,
You are right, I noticed this issue since we introduced #2424
I haven't tried but you should be able to just call SetScrollX(0) after Begin() to clear it?

[pixtur]

Excellent solution. Why didn't I find this work around myself?!
Thanks a lot for your quick help.

[ocornut]

I don't know which version you are using (Edit: 1.70 as stated above, sorry ^^), but unfortunately this won't work correctly from 1.72 (just tried and this is causing a glitch).

This is directly in opposition to what we tried to achieve with dcd03f6

"Scrolling: Made it possible for mouse wheel and navigation-triggered scrolling to override a call to SetScrollX()/SetScrollY(), making it possible to use a simpler stateless pattern for auto-scrolling."

[ocornut]

One option would be to add explicit window flags e.g. ImGuiWindowFlags_NoScrollX

Pro: explicit
Con: not as flexible
Con: trying to not allocate too many window flags

Or we could expose SetNextWIndowScrollX() function

Pro: which would allow solve things like #1526
Pro: generally be more flexible.
Con: not as explicit to solve this specific problem you have
Con: still adding a new api
Con: api name gets akward because other SetScrollXXX function don't have the word "Window" in their name, but all SetNextXXX functions do. So that would be a small inconsistency we can maybe fix in 2.0.

[pixtur]

Wow, thanks for your effort. I personally don't know enough to have a valid opinion, and could live with both solutions. At least in 1.70 horizontal an vertical scrolling are handled somewhat inconsistently within the API. If possible, I would prefer verbose, explicit and consistent flags and methods for both directions.

[pixtur]

@ocornut I finally wanted to bump our version to v1.72 but the glitch you mentioned also appears for the vertical scrolling.

I already added a work around like this some months ago...

ImGui.SetScrollY(0);    // HACK: prevent jump of scroll position by accidental scrolling

...but forgot about it and didn't considered relevant for the horizontal scroll problem. In v1.72 it appears that the scroll position override is applied with a one frame delay. This results in considerable flickering when zooming in with mouse wheel.

It's barely noticable in the gif because of the low framerate, but with 60fps it appears every time and I want to find a solution or work around. I already disabled the scrollbars. Is there a way to disable the mouse wheel and for certain windows?

[pixtur]

@ocornut I just had one more insight: I now believe that scrolling should be completely decoupled from mouse-wheel interaction. There are many use-cases in which the mouse-wheel is used for zooming (timelines, image viewers, maps etc.). But frequently you still want to display and use the scrollbars if the outer dimension of the zoomed canvas are known.

I that's why my preferred solution would be a flag like IgnoreMouseWheel.

This would fix my current issues, and I believe it should be easy to integrate.

[ocornut]

For the later I think you should be able to use ImGuiWindowFlags_NoScrollWithMouse.

[pixtur]

Excellent. How could I have missed this option?! Again.
Thanks a lot!

[frink]

I think that solving for scrolling cases ImGuiWindowFlags_NoScrollX and ImGuiWindowFlags_NoScrollY would actually be more flexible... You often want to scroll in one direction only. While Horizontal Scroll is more rare I can think of half a dozen cases where NoScollY could be handy. Essentially your doing this for tabbars and menubars internally already.

As far as flag pollution, it's a bit like style vars... Always better to have too many than not enough.

[frink]

I've tried the ImGui::SetScrollX(0) but it's jumpy. I'll dig into the flags and put a PR together...

[ocornut]

As far as flag pollution, it's a bit like style vars... Always better to have too many than not enough.

Unfortunately no because we have a limited amount of window flags (32-bits) and docking branch use more. Working on removing 1-2 from docking branch.

[frink]

Unfortunately no because we have a limited amount of window flags (32-bits) and docking branch use more. Working on removing 1-2 from docking branch.

Okay. I understand your comment now:

...trying to not allocate too many window flags

Looks like we're left with the only option of exposing SetNextWIndowScrollX() to prevent jumping...

...api name gets akward because other SetScrollXXX function don't have the word "Window" in their name, but all SetNextXXX functions do.

Tabs, docking titles, and multi-line text entry all have scrolling too so we should probably be pedantic in naming unless the other widgets could also take SetNextScrollX() which is unlikely.

Would you be open to a PR exposing SetNextWindowScrollXXX()?

This itch is annoying enough that I'm ready to scratch it!!

[Mielie]

Hi,

Any progress on this issue? I need to allow the user to scroll vertically but not horizontally. Using SetNextScrollX() causes jumping.