_WinAPI_HiWord and LoWord: signing mismatch?

[danielkza]

_WinAPI_HiWord() and _WinAPI_LoWord() seem to have inconsistent treatment of their parameters. The former seems to treat integers as signed, and the latter as unsigned. See this simple example:

#include <WinAPI.au3>
Global $Test = 0xFFFFFFFF

MsgBox(0, "HiLoWord Test", "HiWord: " & _WinAPI_HiWord($Test) & @CRLF & _
                           "LoWord: " & _WinAPI_LoWord($Test) & @CRLF)

; [Output]
; HiWord: -1
; LoWord: 65535

Is that intended behavior? I believe both functions should output the same value in this example, as both the low and high words are 0xFFFF.

Edited March 8, 2011 by danielkza

[JohnOne]

Maybe it dosent like the 8 fs

Global $Test = 0xFFFFFF works.

[danielkza]

Maybe it dosent like the 8 fs

Global $Test = 0xFFFFFF works.

It works by accident, because 00FF happens not to have the sign bit set. 0xFFFFF0FF (-1, signed -3841 ) is returned as (-1, unsigned 61695) too, for instance.

[kylomas]

danielkza,

There is NO inconsistent behavior, nor is this an accident. $test is a double word with the sign carried in the most significant bit. When you break this into two words the low order word is positive and the hi order word is negative in your example. Google data representation for detailed explanations.

kylomas

[danielkza]

danielkza,

There is NO inconsistent behavior, nor is this an accident. $test is a double word with the sign carried in the most significant bit. When you break this into two words the low order word is positive and the hi order word is negative in your example. Google data representation for detailed explanations.

kylomas

The sign bit would matter if I were trying to represent a single integer as a doubleword. In my case, the dword happens to be the concatenation of two separate words. The most significant bit is not a sign bit: it is simply part of one of the words. LoWord and HiWord exist for that exact case that shows up quite often in the Windows API. Since the values they return are always single words, they should treat them as so, and not carry the sign bit from whatever intermediate representation exists inside them (that's what is happening on the current code, with BitAND treating all it's parameters as unsigned).

This behavior is not consistent with the function's goals. I ran into the problem while handling the WM_CONTEXTMENU message. See some of the description:

xPos = GET_X_LPARAM(lParam); 
yPos = GET_Y_LPARAM(lParam);

If the context menu is generated from the keyboard—for example, if the user types SHIFT+F10—then the x- and y-coordinates are -1 and the application should display the context menu at the location of the current selection rather than at (xPos, yPos).

GET_X_PARAM is defined as

((int)(short)LOWORD(lp))

I tried the most obvious code, which obviously doesn't work.

Local $PosX = _WinAPI_LoWord($lParam), $PosY = _WinAPI_HiWord($lParam)
If $PosX = -1 And $PosY = -1 Then
  ; Do Stuff
EndIF

This issue should at least be documented somewhere. I spent 1:30h debugging the rest of my code because I never expected LoWord and HiWord not to work as they would in C code. A notice in the help file would be very helpful already.

Edited March 8, 2011 by danielkza

[MvGulik]

Did you take in consideration that auotit(oops) autoit only has and uses signed integer's. (int32 or int64 flavor)

Anyway. Its always a good thing to check any assumptions ... if your not completely 100% sure about how something might work or turn out ... in a other code language.

Edited March 8, 2011 by iEvKI3gv9Wrkd41u

[kylomas]

danielkza,

This is one of those issues that can be argued forever, depending on expectations and point of view. I do agree with you on one point, the doc for the WinAPI could be better. On the other hand...

You get my point, I hope!

kylomas

[danielkza]

Did you take in consideration that auotit(oops) autoit only has and uses signed integer's. (int32 or int64 flavor)

Anyway. Its always a good thing to check any assumptions ... if your not completely 100% sure about how something might work or turn out ... in a other code language.

If both numbers were treated as signed it would work exactly as I expect. The problem is that BitAND treats it's arguments as unsigned, messing up everything. If this was documented I would indeed have found out about it early on, but unfortunately it is not.

danielkza,

This is one of those issues that can be argued forever, depending on expectations and point of view. I do agree with you on one point, the doc for the WinAPI could be better. On the other hand...

You get my point, I hope!

kylomas

I'd be satisfied as long as things were consistent, with both words treated as signed or unsigned.

[MvGulik]

... The problem is that BitAND treats it's arguments as unsigned, ..

... Wow ... I'm out.

[Malkey]

Here's my two cents worth.

Does Yes = Si = Oui = Da = Ya ?

Answer: Yes and no.

Does -1 = 0xFFFFFFFF?

Answer: Yes and no. (signed and unsigned integers)

Here's Post #1 example completed.

#include <WinAPI.au3>
Global $Test = 0xFFFFFFFF

MsgBox(0, "HiLoWord Test", "0xFFFFFFFF: " & 0xFFFFFFFF & @CRLF & _
                                                        "HiWord: " & _WinAPI_HiWord($Test) & @CRLF & _
                        "LoWord: " & _WinAPI_LoWord($Test) & @CRLF & _
                        "HiWord: " & hex(_WinAPI_HiWord($Test),4) & @CRLF & _
                        "LoWord: " & hex(_WinAPI_LoWord($Test),4) & @CRLF)

#cs 
[Output]
0xFFFFFFFF: -1
HiWord: -1
LoWord: 65535
HiWord: FFFF
LoWord: FFFF

[Copied from WinAPI.au3 include file.]
Func _WinAPI_HiWord($iLong)
    Return BitShift($iLong, 16)
EndFunc   ;==>_WinAPI_HiWord

Func _WinAPI_LoWord($iLong)
    Return BitAND($iLong, 0xFFFF)
EndFunc   ;==>_WinAPI_LoWord
#ce

This works.

#include <WinAPI.au3>

Local $lParam = 0xFFFFFFFF
Local $PosX = Hex(_WinAPI_LoWord($lParam), 4), $PosY = Hex(_WinAPI_HiWord($lParam), 4)

If "0X" & $PosX = 0xFFFF And "0X" & $PosY = 0xFFFF And $PosX = "FFFF" And $PosY = "FFFF" Then ;
    MsgBox(0, "Results", "$PosX And $PosY equal.")
EndIf

[Yashied]

Method 1

Global $Test = 0xFFFFFFFF

$PosX = BitAND($Test, 0xFFFF)
$PosY = BitShift($Test, 16)
If $PosX > 0x7FFF Then $PosX -= 0x10000
If $PosY > 0x7FFF Then $PosY -= 0x10000

MsgBox(0, "HiLoWord Test", "HiWord: " & $PosX & @CRLF & _
                           "LoWord: " & $PosY & @CRLF)

Method 2

Global $Test = 0xFFFFFFFF

$tStruct1 = DllStructCreate('dword XY')
$tStruct2 = DllStructCreate('short Y;short X', DllStructGetPtr($tStruct1))
DllStructSetData($tStruct1, 'XY', $Test)
$PosX = DllStructGetData($tStruct2, 'X')
$PosY = DllStructGetData($tStruct2, 'Y')

MsgBox(0, "HiLoWord Test", "HiWord: " & $PosX & @CRLF & _
                           "LoWord: " & $PosY & @CRLF)

[danielkza]

Thank you guys, I had found a workaround already (in this particular case I just need to check for -1 in both words, so checking for 0xFFFFFFFF is enough). Maybe'll file a bug report one of these days asking if the devs want to change it or at least document things better.

Edited March 9, 2011 by danielkza

[matwachich]

The feature request would be to add functions:

_WinAPI_GetXParam and _WinAPI_GetYParam

Here is my attempt

Func _WinAPI_GetXParam($lParam)
    $t = DllStructCreate("dword XY")
    $t.XY = $lParam
    $t2 = DllStructCreate("short X; short Y", DllStructGetPtr($t))
    Return $t2.X
EndFunc

Func _WinAPI_GetYParam($lParam)
    $t = DllStructCreate("dword XY")
    $t.XY = $lParam
    $t2 = DllStructCreate("short X; short Y", DllStructGetPtr($t))
    Return $t2.Y
EndFunc

 

[Nine]

Lol 10 years after.  One of my favorite rock groups.  Kind of useless answer IMHO.