Strange mouse wheel results

[Ophelius]

The mouse wheel doesn't work until at least 3 consecutive clicks up or down has been registered, then it works fine after each click in the same direction. If you change direction, it then takes another 3 clicks in that direction to get it started. If you go back and forth between up and down never clicking more than 2, it'll never register a wheel click. Example, this sequence won't cause any click: go up 2, down 2, up 1, down 1, up 2, down 1, up 2, down 2...this will never scroll the wheel. But as soon as you hit that 3rd click in the same direction it works in that direction every click.

I tried the simplest example in the help, same problem:

Code: QB64: [Select]

1. DO: _LIMIT 100
2.     DO WHILE _MOUSEINPUT
3.         Scroll = Scroll + _MOUSEWHEEL
4.         LOCATE 10, 20: PRINT Scroll
5.     LOOP
6. LOOP UNTIL INKEY$ = CHR$(13) ' press Enter to quit
7.  

It's not my mouse, the scrolling works fine everywhere else in Windows.

Any idea?

[FellippeHeitor]

Does this make a difference?

Code: QB64: [Select]

1. DO: _LIMIT 100
2.     DO WHILE _MOUSEINPUT
3.         Scroll = Scroll + _MOUSEWHEEL
4.     LOOP
5.     LOCATE 10, 20: PRINT Scroll
6.     _DISPLAY
7. LOOP UNTIL INKEY$ = CHR$(13) ' press Enter to quit
8.  

[Ophelius]

Does this make a difference?

Code: QB64: [Select]

1. DO: _LIMIT 100
2.     DO WHILE _MOUSEINPUT
3.         Scroll = Scroll + _MOUSEWHEEL
4.     LOOP
5.     LOCATE 10, 20: PRINT Scroll
6.     _DISPLAY
7. LOOP UNTIL INKEY$ = CHR$(13) ' press Enter to quit
8.  

No, same thing. One thing to note is the 1st scroll after the program starts takes 2 clicks to get going, not 3. But then it's back to 3 when changing directions as stated above

[Cobalt]

Does pretty much the same thing for me when trying to scroll through code in the IDE. 1 or 2 click delay before things start happening, but it also does this in most games I play that make use of the scroll wheel. I always thought that was intended behavior or hardware behavior just in case the user bumped the scroll wheel so they did get constant jittering around.

[Ophelius]

Does pretty much the same thing for me when trying to scroll through code in the IDE. 1 or 2 click delay before things start happening, but it also does this in most games I play that make use of the scroll wheel. I always thought that was intended behavior or hardware behavior just in case the user bumped the scroll wheel so they did get constant jittering around.

Good that it's not just me. I've never seen behavior like that in any other game or software. It's a tad annoying in my opinion that the QB64 IDE does this, and also anything compiled with QB64 will do this. The mouse wheel should respond the 1st scroll click you make. It does seem like an internal counter is counting. No matter how slow you click, when that counter counts to 3 it allows clicks in that direction, and resets itself when changing direction.

Devs: Is this intentional? Is this a feature programmed into QB or is this a possible bug?

[OldMoses]

I get the same behaviour, but I don't think it's the fault of QB64. I've seen it in other applications. My money is on the OS, or hardware. I'm using a Logitech M510 wireless, which has been dropped on the floor at least a couple times a day. I've never really looked into trying to fix it, just figured it was normal.

[Ophelius]

I get the same behaviour, but I don't think it's the fault of QB64. I've seen it in other applications. My money is on the OS, or hardware. I'm using a Logitech M510 wireless, which has been dropped on the floor at least a couple times a day. I've never really looked into trying to fix it, just figured it was normal.

Hmm, that's weird. I tried it on 2 different mice, same thing, and I've never experienced this other than with the Qb64 editor and programs compiled with it

[OldMoses]

Revisiting this, I stand corrected from my earlier post, I note that in working on my star system simulator application the effect that never bugged me before, becomes more pronounced when you have occasion to use the wheel for fine control.

I recently added a mouse wheel zooming capability, whereby rolling the mouse one direction zooms in, while rolling the other way zooms out. Similar to applications such as various CAD aps and Blender. Additionally, clicking the mouse wheel returns to a default zoom factor. Each detent of the mouse wheel, or what I'll refer to as a "roll click", results in a halving or doubling of the zoom factor. Here is where the mouse action becomes most noticeable.

As Ophelius noted earlier, the precise behaviour seems to be that rolling the mouse wheel in one direction will yield the desired results. You can stop and then continue without any issues. However, reversing the mouse wheel direction will result in two "dry roll clicks" of the wheel, where nothing will happen in the application, and the desired effect will start on the third "roll click". Clicking the wheel as you would a button doesn't reset the behaviour in any way. For some reason QB64 chooses to ignore two wheel detents upon reversal.

I never thought much of it before, as it wasn't as noticeable in the IDE, given that I was rapidly rolling the wheel through large blocks of code and never had occasion for finer control.

I went to a Blender project I'm working on and it would not duplicate the effect, so it's obviously not a hardware or OS issue, unless its associated with certain individual systems and their interaction with the IDE. QB64 and its compiled applications seems to consistently lose two mouse wheel detents when reversing the wheel.

[RhoSigma]

I've noticed this behavior a good while ago when implementing wheel actions into GuiTools, eg. to move scroll bars, sliders, listviews etc.. I fully agree it must be a fault of QB64, or more specific the OpenGL mouse routines used, because with the old SDL based QB64 versions there's no such click delay when reversing the scroll direction. It works as expected from the first wheel click in old QB64 SDL (v0.954), so it's definitly something introduced with the transition to OpenGL between versions 0.954 and 1.000.

[bplus]

I swear I hear an echo from a month or two ago when all were befuddled by an extra click needed for the mouse wheel.

You guys are so sensitive ;-))

[OldMoses]

I swear I hear an echo from a month or two ago when all were befuddled by an extra click needed for the mouse wheel.

You guys are so sensitive ;-))

You should see me when I get a pebble in my shoe...;)

[TempodiBasic]

Hi
about

QB64 and its compiled applications seems to consistently lose two mouse wheel detents when reversing the wheel.

yes also I experiment this. But I use massively mouse wheel with no one movement at a time, so I have had no issue from this loose of 2-3 click in the reverse of mousewheel.  Surely in a more sensitive system for an accurate action of mouse, this 2-3 click of mousewheel must be managed to avoid different reaction of program to the action of rotating mousewheel.
However looking at Panel Control of Windows, in the section Mouse you can see that for default the mousewheel has its settings in which in my PC appears a number 3.... is it important for the issue talked here?