Sign in to follow this  
Gink

HIWORD LOWORD macros question / short data type

Recommended Posts

This program is lets you draw a box, when the mouse is released it should be drawn. In this snippet of code, I dont understand why these values have to be casted to short. When they aren't short, whenever the mouse goes into negative coordinates(left of the window or above it), it ends up going to the far right or bottom instead. I dont understand why casting it to short fixes the problem. Here is HIWORD - #define HIWORD(l) ((WORD) (((DWORD) (l) >> 16) & 0xFFFF)) LOWORD - #define LOWORD(l) ((WORD) (l))


  case WM_MOUSEMOVE :
          if (fBlocking)
          {
               SetCursor (LoadCursor (NULL, IDC_CROSS)) ;
               
               DrawBoxOutline (hwnd, ptBeg, ptEnd) ;
               
               ptEnd.x = (short) LOWORD (lParam) ;
               ptEnd.y = (short) HIWORD (lParam) ;
               
               DrawBoxOutline (hwnd, ptBeg, ptEnd) ;
          }
          return 0 ;
          
     case WM_LBUTTONUP :
          if (fBlocking)
          {
               DrawBoxOutline (hwnd, ptBeg, ptEnd) ;
               
               ptBoxBeg   = ptBeg ;
               ptBoxEnd.x = (short)LOWORD (lParam) ;
               ptBoxEnd.y = (short)HIWORD (lParam) ;
               
               ReleaseCapture () ;
               SetCursor (LoadCursor (NULL, IDC_ARROW)) ;
               
               fBlocking = FALSE ;
               fValidBox  = TRUE ;
               
               InvalidateRect (hwnd, NULL, TRUE) ;
          }
          return 0 ;


Share this post


Link to post
Share on other sites
WORD, the final casting of the HIWORD/LOWORD macros, is defined as an unsigned short. They have to cast to (signed) short to be correctly interpreted.

Share this post


Link to post
Share on other sites
What information? Casting from unsigned short to signed short like that, and visa versa, just changed the way the data is interpreted in this case. The bit pattern stays the same. It's signed values that are being packed into the LPARAM. It's signed values that you want to extract.

Share this post


Link to post
Share on other sites
Consider this bunch of bits: 11111111. If you treat this as a WORD (i.e. 16-bit unsigned) it has the decimal value 65535. On the other hand if you treat the *exact same* bits as a short instead (i.e. 16-bit signed) it now has the value -1.

Share this post


Link to post
Share on other sites
Why would it treat 1111 1111 as 65535? Wouldnt it be 255? I dont see why it would be -1 either.

Share this post


Link to post
Share on other sites
Whoops, you're right. I meant 1111111111111111 (16 ones). Anyway, you might want to google for "twos complement" for more info about how bits get translated to numbers.

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now

Sign in to follow this