Jump to content
  • Advertisement
Sign in to follow this  
Gink

HIWORD LOWORD macros question / short data type

This topic is 4870 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

If you intended to correct an error in the post then please contact us.

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
Advertisement
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
wouldnt that information be lost if it was casted to WORD then to a short?

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
Sign in to follow this  

  • Advertisement
×

Important Information

By using GameDev.net, you agree to our community Guidelines, Terms of Use, and Privacy Policy.

We are the game development community.

Whether you are an indie, hobbyist, AAA developer, or just trying to learn, GameDev.net is the place for you to learn, share, and connect with the games industry. Learn more About Us or sign up!

Sign me up!