MouseWheel Message - What Should wParam Return?

[Gary Beene]

I read this at MSDN, regarding the WM_MouseWheel message.

A positive value indicates that the wheel was rotated forward, away from the user; a negative value indicates that the wheel was rotated backward, toward the user.

But that's not what is returned. 120 or 65416 are the two values returned, depending on the direction I roll the wheel.

In the forum I found this code, which corresponds with what I am seeing.

    CASE %WM_MOUSEWHEEL ' Mouse wheel
      wm = HI(WORD, wParam): IF wm>32768 THEN wm=-1 ELSE wm=1 ' Wheel turned (+)=up (-)=down

Is there other documentation at MSDN that explains what I am seeing? I seem to have missed that paragraph!

[Chris Holbrook]

65416

That's negative if you map it onto a WORD rather than a LONG.

[Michael Mattias]

> That's negative if you map it onto a WORD rather than a LONG

No, WORDs are never "negative." He needs an INTEGER

[Gary Beene]

I tested it this way:

Select Case Hi(Word,wParam)
   Case > 0
   Case > 0
   Case Else
Select Case

[Gary Beene]

And now that you've sent me in the right direction, Help says this:

The value returned by HI is unsigned if type is BYTE, WORD, or DWORD, and signed if type is INTEGER or LONG. value may be up to twice the size of the data type specified by type.

So my choice of WORD was inappropriate to extract a positive/negative return value. I could have used either of these to get a signed result.

Select Case Hi(Long,wParam)
Select Case Hi(Integer,wParam)

I tried both and they seem to work. But - MSDN didn't say how large the result could be, only whether it was postive/negative. So LONG would seem the appropriate choice.

In the test, however, the returned value was within INTEGER range - hence my test showed both INTEGER/LONG to work.

[colin glenn]

You would want to stick with using an Integer because the LO word is used to pass the state of the other buttons in addition to the Shift & Control keys, and the XButton's, if any.

[Gary Beene]

Hi Colin,

Actually, your statement brings up a question.

I understood it to work that what I put in Hi(type,value) for the position type does not determine what is retrieved - that Hi always returns only the the upper 16 bits, then the results are returned as the specified variable type.

Per Help:

Extract the most significant (high-order) portion

But when I test this, the answers are not the same!

      MsgBox Str$(Hi(Long,wparam))
      MsgBox Str$(Hi(Integer,wparam))

You're suggesting that the lower word is included in the result, depending on the value of type? Is that right?

So perhaps I've misunderstood your comment or what Help says. Or, perhaps I tested wrong? For sure, my test didn't give the result I was expecting.

[Michael Mattias]

>But - MSDN didn't say how large the result could be,

Um, how many bits would be in the HI or LO word of a 32-bit "wparam?"

!!!!!

[colin glenn]

No, they won't be the same, HI(LONG, {DWORD VALUE}) = DWORD value, just suddenly with a sign bit, essentially the exact same value you passed to the function as far as the bits are concerned. In your case, the results are going to include the LO part of the word, multiplying the results by 65,536.

[Gary Beene]

Hi MCM,

That part I know.

Until this discussion, though, I didn't understand the MSDN entry on WM_MouseWheel to say it extracts the value of wParam, only that the result of the message is positive or negative (of value unknown).

Poor reading on my part, apparently.

I guess my general suspicion of MSDN documentation led me into too much "lawyering" of the documentation.

[Gary Beene]

oooh ooooh (an MCM saying).

So "type" is not the number of bits in the returned value of HI, but rather the number of bits extracted from the "value" (which could be placed in a type of equal or greater bits, but isn't in this case).

But, what sense does it make to say "extract the hi-order portion" when the value being extracted is the entire number of bits in the value, such that there is no lo-order portion "left behind"? It seems misleading, even if it is technically accurate. This means that depending on how many bits you want to extract, the hi-order and lo-order portions could be the same!

I guess I took the extraction comments to vaguely mean that the value bits were split into 2 parts - hi and lo - of equal bits. Then the extracted bits were placed in a variable of type. It's not the first time I've mis-interpreted documentation.

[Michael Mattias]

IF BIT(LongInt&, 15) THEN 
    HI (WORD, LongInt& ) is negative

I think. IIRC HI(WORD, long) gets the 16 bits at VARPTR(longint)+2 (the MSW).

(Sheesh, you just use this stuff so much you get into 'auto-mode' and forget from whence it comes. My bad).

If it ain't that for sure it's IF BIT(LongInt&,31) THEN HI(WORD,LongInt&) is negative

(The word "negative" used here only for consistency with stated problem. After all, it's just a bit. How you interpret it is up to you).

MCM

[Jeff Blakeney]

The PB documentation for the HI and LO commands say that the value you pass it can be "up to" twice the size of the type you specify. However, it doesn't say what the behaviour is when the value isn't twice the size of the type. The result of doing a HI(LONG, LongVar) is undefined because the high long of a long variable doesn't exist so will either return garbage data but probably should return a 0 but the documentation doesn't actually specify that.

Best to always make sure the value passed in is twice the size of the type that you want and you won't run into problems.

[Michael Mattias]

FWIW, there are at least four ways to make sign-agnostic integer equality comparisons using only intrinsic functions...

XOR
SELECT CASE AS LONG (available PB/Win 7+)
BITSE (available PB/Win 9+)
IF or SELECT CASE (using PB/DLL 6-)