If OpenWindow(0,300,300,160,55,"MouseWheel",#PB_Window_SystemMenu)
TextGadget(0,20,20,150,20,"Scroll the mouse wheel...")
Repeat
ev=WaitWindowEvent()
If ev=#WM_MOUSEWHEEL
dir=-(EventwParam()>>16)/#WHEEL_DELTA
Debug dir
If dir=-1 ; For both 64bit and 32bit
SetGadgetText(0,"UP")
Else ; -545 on 64bit, 1 on 32bit
SetGadgetText(0,"DOWN")
EndIf
EndIf
Until ev=#PB_Event_CloseWindow
EndIf
Dude wrote:The code I posted above is no longer useful for 64bit PureBasic because it doesn't return negative or positive values for the wheel direction. Is there some sort of ">>" math trick to make it work again?
Okay, I understand now. (Edited my reply for you).
But when I tested Dude's code, it only showed "UP" for me as well on 5.71 64bit (Windows). So the code I posted was my fix. Strange that it shows UP/DOWN for you but not for us?
Thank you RASHAD for remembering my cross-platform example which demonstrates how to detect moving the mouse wheel up or down in a ListIconGadget.
My adapted code of Dude's original TextGadget example is very similar to BarryG's one but a little bit shorter and also working with PB 5.71 x86 and x64 on Windows:
If OpenWindow(0,300,300,160,55,"MouseWheel",#PB_Window_SystemMenu)
TextGadget(0,20,20,150,20,"Scroll the mouse wheel...")
Repeat
ev=WaitWindowEvent()
If ev=#WM_MOUSEWHEEL
If (EventwParam() >> 16) & $8000
SetGadgetText(0,"DOWN")
Else
SetGadgetText(0,"UP")
EndIf
EndIf
Until ev=#PB_Event_CloseWindow
EndIf
BarryG wrote:...
But when I tested Dude's code, it only showed "UP" for me as well on 5.71 64bit (Windows). So the code I posted was my fix. Strange that it shows UP/DOWN for you but not for us?
Windows 10, PureBasic 64-bit, EventwParam() = $78000 for up, $FF880000 for down (same as Win 7). Since both of these are positive numbers, Dude's test using "<0" and ">0" doesn't work for me; hence my example above that I had to use.
All these codes have a problem. Not every mouse (mousewheel without grid) returns a value of 120 units. This value can be much finer, so the values have to be summed up:
You don't have to rely on the value of transmitted data.
Just test if param is negativ then subtract 1, else add 1.
Afterwards you can decide what step size are neccessery.
For example a scrollbar can make 1 step or 10 or 50.
You don't have to be concerned about, what granularity
the mouse has.
No, that's not right. If you have a high resolution mouse wheel, you can get 1, 3, 9, 19, 70 or any number of events in the area that normally corresponds to one notch on the mouse wheel. Then your ListIconGadget (or whatever) would jump 1, 3, 9, 19, 70 number of lines up or down, although it should only be one line. Using a high resolution mouse wheel, the number of sent events is a random value for you, only the summed up values will give you a reliable result independent of the mouse used.
The method with the summed up values is by the way:
- recommended by Microsoft
- used by Pb for the CanvasGadget
Of course, you don't always have to check for a value of 120. For example, if you use the standard Windows text editor, the text will always scroll four lines if you use a standard mouse with notches. If you create something like this yourself, you could also check to a value of 30, so the behavior remains the same for all mice, but the user of a mouse with a high-resolution wheel then has the additional advantage that he can scroll with the mouse wheel with fine operation also one single line.
@Josh
My posting refers for example to a manually updated scrollbar.
You need only the direction up or down and the decide how
many steps you go up or down.
I should have written: "You don't have always to rely on the
value of transferred data."