Bug in mouseZspeed()

Archives Forums/Blitz3D Bug Reports/Bug in mouseZspeed()

Ross C

(Posted 2006) [#1]

Run this code and use the scroll button on your mouse to scroll for a bit, then click away from the window, onto any other window. MouseZSpeed() is only supposed to return either -1,0 or 1. But it seems like blitz or some other force, keeps track of how much scrolling has been done, and returns this value when clicked outside of the blitz window.

Rather annoying, as my editor uses this for zooming, so when i click away, it zooms right back in :P

While Not KeyHit(1)
	temp1 = MouseZSpeed()
	If Abs(temp1) > 1 Then RuntimeError(" mouse Z speed has stored: = "+temp1)
Wend

Funnily enough, the same happens with mouseZ()

While Not KeyHit(1)
	temp1 = MouseZ()
	Print temp1
Wend

H&K	(Posted 2006) [#2]

Keep the milli timer variable (which I imageine you already have in the program), then just before you start to mouse, (new verb :)) check to see if loads of time have passed. If it has then clear the mousebuffer

Ross C

(Posted 2006) [#3]

Its still surely a bug? I don't have a millisecs() value. IF you use mouseZspeed() for anything, then you'll run into this problem. It shouldn't really return a number bigger or smaller than 1/-1. If have found a way around it. Just thought i'd report it :)

H&K	(Posted 2006) [#4]

Oh. It seems to do it only when the consol/program is not in focus. (ie its not when you return to the application, but when you leave in). Strange

Sledge

(Posted 2006) [#5]

The strange number you get for mousezspeed() is the inverse sum of its reports since the program has been in focus. So if you wheeled -2,-1,-1,-2 then clicked on another program/the desktop the extra figure you would get would be 6. Or, in other words, -MouseZ(). When the program loses focus it seems as if the z coord for the mouse "springs back" to zero.

Try dialing the mousewheel then clicking on the desktop with the following code. You will see that what you wheel when the program loses focus does not matter - what you are really seeing is the behaviour described above.

While Not KeyHit(1)
	temp1 = MouseZSpeed()
	If Not temp1=0 Then Print temp1+"         "+MouseZ()
Wend

This might not be a bug (you could certainly argue that it's a "feature") but it's definitely troublesome. Would be nice to see "fixed".

It shouldn't really return a number bigger or smaller than 1/-1.

Stop trusting the docs, they get lots of things wrong. If the mouse wheel is dialed fast then it should return a much higher/lower figure. You wouldn't expect the mouse to move in single unit increments on the x and y axis, would you?

EDIT: Fixed for clarity

Sledge

(Posted 2006) [#6]

By the way, one possible fix would be to give MoveMouse a z component. Then we could maintain mouse z up around 200 or something (higher than anyone could dial in one frame) so it would be immeditalely obvious, when the value sprang back to zero, that the program had lost focus and that the current report should be ignored. (Or perhaps there is a solution using the current info we have access to - Mark?)

Ross C

(Posted 2006) [#7]

I just say, if the ABS of mousexspeed() is > 1 then, disreguard :o)