We are currently migrating Bugzilla to GitHub issues.
Any changes made to the bug tracker now will be lost, so please do not post new bugs or make changes to them.
When we're done, all bug URLs will redirect to their equivalent location on the new bug tracker.

Bug 2518 - Mouse Wheel Event is being affected by Mouse motion
Summary: Mouse Wheel Event is being affected by Mouse motion
Status: RESOLVED INVALID
Alias: None
Product: SDL
Classification: Unclassified
Component: events (show other bugs)
Version: 2.0.3
Hardware: x86 Windows 8
: P2 normal
Assignee: Sam Lantinga
QA Contact: Sam Lantinga
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2014-05-02 00:43 UTC by jhlshhs
Modified: 2014-05-11 18:37 UTC (History)
1 user (show)

See Also:


Attachments
values of mouse wheel y and mouse position x (11.63 KB, image/png)
2014-05-02 00:43 UTC, jhlshhs
Details

Note You need to log in before you can comment on or make changes to this bug.
Description jhlshhs 2014-05-02 00:43:02 UTC
Created attachment 1638 [details]
values of mouse wheel y and mouse position x

SDL_MouseWheelEvent's y (the amount scrolled vertically) is being affected whenever the mouse is in motion. Looking at the value of y when the mouse is moving it seems the value of y is being replaced by the SDL_MouseMotionEvent's x (the X coordinate of the mouse, relative to the window).
Comment 1 Adam M. 2014-05-10 23:10:03 UTC
I don't see this behavior on Windows 7, anyway. If I move the mouse and scroll vigorously, I only ever see a y value of 1 or -1 in the mouse wheel event. Can you post a test program that reproduces this?
Comment 2 jhlshhs 2014-05-11 17:37:55 UTC
(In reply to Adam M. from comment #1)
> I don't see this behavior on Windows 7, anyway. If I move the mouse and
> scroll vigorously, I only ever see a y value of 1 or -1 in the mouse wheel
> event. Can you post a test program that reproduces this?

I found that the reason for this problem was because I was trying to access the wheel value (evnt.wheel.y) outside of the while (SDL_PollEvent(&evnt) != 0). I’m guessing then that the SDL_Event wasn’t designed to be used like that? I managed to work around this by simply saving the value of the wheel in a local variable and then accessing it later outside the loop. I apologize for the inconvenience since this was just a user error on my part.

Thank You for your time
Comment 3 Adam M. 2014-05-11 18:35:03 UTC
No need for apologies. SDL has terrible documentation, and it's often not clear what the best practices are for using it, or whether a particular behavior is correct or not.

That said, this behavior doesn't sound like a quirk of SDL. I don't believe SDL is going to overwrite your event except when you ask it to, although I would only be 90% shocked if that turned out to be the case.

If your code is like:

SDL_Event e;
while(SDL_PollEvent(&e))
{
  // process event
}

Then 'e' will be overwritten on every iteration of the loop, so outside the loop you'll only see the event from the last iteration. SDL_Event is a union, which means that e.wheel, e.motion, e.window, etc. all share the same storage space in memory. So when one is overwritten, they all are. (But even if that were not the case, you should not expect a function that returns a structure like this to preserve any part of it unless it's explicitly documented to do so.) The only case where you can expect to use the mouse wheel information outside the loop is something like this:

SDL_Event e;
while(SDL_PollEvent(&e))
{
  if(e.type == SDL_MOUSEWHEEL) break;
  // other event processing
}
// use e.wheel.x here
Comment 4 Adam M. 2014-05-11 18:37:21 UTC
(But even then you can't be sure whether it exited the loop because of a MOUSEWHEEL event or because it ran out of events...)