Announcement

Collapse
No announcement yet.

MouseWheel Message - What Should wParam Return?

Collapse
X
 
  • Filter
  • Time
  • Show
Clear All
new posts

  • MouseWheel Message - What Should wParam Return?

    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.

    Code:
        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!

  • #2
    Originally posted by Gary Beene View Post
    65416
    That's negative if you map it onto a WORD rather than a LONG.

    Comment


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

      No, WORDs are never "negative." He needs an INTEGER
      Michael Mattias
      Tal Systems (retired)
      Port Washington WI USA
      [email protected]
      http://www.talsystems.com

      Comment


      • #4
        I tested it this way:

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

        Comment


        • #5
          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.

          Code:
          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.
          Last edited by Gary Beene; 13 Nov 2009, 08:41 PM.

          Comment


          • #6
            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.
            Furcadia, an interesting online MMORPG in which you can create and program your own content.

            Comment


            • #7
              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!

              Code:
                    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.
              Last edited by Gary Beene; 13 Nov 2009, 08:58 PM.

              Comment


              • #8
                >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?"

                !!!!!
                Michael Mattias
                Tal Systems (retired)
                Port Washington WI USA
                [email protected]
                http://www.talsystems.com

                Comment


                • #9
                  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.
                  Furcadia, an interesting online MMORPG in which you can create and program your own content.

                  Comment


                  • #10
                    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.

                    Comment


                    • #11
                      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.

                      Comment


                      • #12
                        Code:
                        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
                        Michael Mattias
                        Tal Systems (retired)
                        Port Washington WI USA
                        [email protected]
                        http://www.talsystems.com

                        Comment


                        • #13
                          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.
                          Jeff Blakeney

                          Comment


                          • #14
                            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-)
                            Michael Mattias
                            Tal Systems (retired)
                            Port Washington WI USA
                            [email protected]
                            http://www.talsystems.com

                            Comment

                            Working...
                            X