Latest Beta

[UEZ]

With Beta mouse wheel is working only in one way:

expandcollapse popup

#include <WindowsConstants.au3>
#include <WinAPI.au3>

HotKeySet("{ESC}", "_Exit")

Global $wheel = 100
;~ Global Const $WM_MOUSEWHEEL = 0x020A ;wheel up/down
Global Const $MSLLHOOKSTRUCT = $tagPOINT & ";dword mouseData;dword flags;dword time;ulong_ptr dwExtraInfo"
;Register callback
$hKey_Proc = DllCallbackRegister("_Mouse_Proc", "int", "int;ptr;ptr")
$hM_Module = DllCall("kernel32.dll", "hwnd", "GetModuleHandle", "ptr", 0)
$hM_Hook = DllCall("user32.dll", "hwnd", "SetWindowsHookEx", "int", $WH_MOUSE_LL, "ptr", DllCallbackGetPtr($hKey_Proc), "hwnd", $hM_Module[0], "dword", 0)


Do
Until Not Sleep(50)


Func _Exit()
    DllCall("user32.dll", "int", "UnhookWindowsHookEx", "hwnd", $hM_Hook[0])
    $hM_Hook[0] = 0
    DllCallbackFree($hKey_Proc)
    $hKey_Proc = 0
    Exit
EndFunc


;http://www.autoitscript.com/forum/index.php?showtopic=81761
Func _Mouse_Proc($nCode, $wParam, $lParam) ;function called for mouse events.. Made by _Kurt
    ;define local vars
    Local $info, $mouseData

    If $nCode < 0 Then ;recommended, see http://msdn.microsoft.com/en-us/library/ms644986(VS.85).aspx
        $ret = DllCall("user32.dll", "long", "CallNextHookEx", "hwnd", $hM_Hook[0], "int", $nCode, "ptr", $wParam, "ptr", $lParam) ;recommended
        Return $ret[0]
    EndIf
    $info = DllStructCreate($MSLLHOOKSTRUCT, $lParam)
    $mouseData = DllStructGetData($info, 3)

    ;Find which event happened
    Select
        Case $wParam = $WM_MOUSEWHEEL
            If _WinAPI_HiWord($mouseData) > 0 Then
                $wheel += 1
            Else
                $wheel -= 1
            EndIf
            ConsoleWrite($wheel & @CRLF)
    EndSelect
    ;This is recommended instead of Return 0
    $ret = DllCall("user32.dll", "long", "CallNextHookEx", "hwnd", $hM_Hook[0], "int", $nCode, "ptr", $wParam, "ptr", $lParam)
    Return $ret[0]
EndFunc ;==>_Mouse_Proc

In v3.3.0.0 is the return of _WinAPI_HiWord($mouseData) is +- 120

In Beta 65416 / 120!

Why is this now different? Is HiWord now returning 64bit instead of 32bit?

Return of $mouseData on wheel movement:

- 00000000FF880000

+ 00780000

...

UEZ

Edited November 6, 2009 by UEZ

[ProgAndy]

BitShift has changed:

MsgBox(0, '', BitShift(4287102976, 16))

[Valik]

Nutster,

Static is still not resizing arrays:

>Running:(3.3.1.5):C:\Program Files\AutoIt3\beta\autoit3.exe "C:\Program Files\AutoIt3\Beta\Examples\Helpfile\Static.au3" 
C:\Program Files\AutoIt3\Beta\Examples\Helpfile\Static.au3 (37) : ==> Cannot make existing variables static.:
Static $Values[$State + 1]
Static ^ ERROR
->12:23:13 AutoIT3.exe ended.rc:1

M23

Static was not changed. We know.

[Valik]

BitShift has changed:

MsgBox(0, '', BitShift(4287102976, 16))

Please open a bug report. And if it's not asking too much, please try every other number-related functions and see if they are broken, too. My guess is yes, many things are broken.

[trancexx]

@ProgAndy, this code shows what happened:

$iNum1 = 4294967295
$iNum2 = 0xFFFFFFFF
$iNum3 = -1

MsgBox(0, "+/- BitShift", BitShift($iNum1, 16) & @CRLF & BitShift($iNum2, 16) & @CRLF & BitShift($iNum3, 16))

[Melba23]

Static was not changed. We know.

Sorry.

Note to self: Read the notes under the first spoiler before posting!

M23

[UEZ]

BitShift has changed:

MsgBox(0, '', BitShift(4287102976, 16))

I did not look deeply in funktion _WinAPI_HiWord() to see that it is BitShift()

Anyway, bug found.

UEZ

[wraithdu]

Really ugly temporary hack (you'll go to hell if you use it):

ConsoleWrite(0xFFF & @CRLF)
ConsoleWrite(_BitShift(0xFFFFFFFF, 20) & @CRLF)
ConsoleWrite(0xFFFF & @CRLF)
ConsoleWrite(_BitShift(0xFFFFFFFF, 16) & @CRLF)
ConsoleWrite(0xFFFFF & @CRLF)
ConsoleWrite(_BitShift(0xFFFFFFFF, 12) & @CRLF)

Func _BitShift($iNum, $iShift)
    If ($iShift <= -32) Or ($iShift >= 32) Then Return SetError(1, 0, $iNum)
    If $iShift = 0 Then Return $iNum
    If $iShift < 0 Then
        ; negative shifts seem to work ok
        Return BitShift($iNum, $iShift)
    Else
        ; handle right shifts of negative numbers
        ; the magic: strip sign bit, shift, add back top bit in new position
        If $iNum < 0 Then Return BitOR(BitShift(BitAND($iNum, 0x7FFFFFFF), $iShift), 2 ^ (31 - $iShift))
    EndIf
    Return BitShift($iNum, $iShift)
EndFunc

[ProgAndy]

I did not look deeply in funktion _WinAPI_HiWord() to see that it is BitShift()

Anyway, bug found.

UEZ

reported. #1285

Checked also BitAnd, BitNot and BitOr and found the error in BitNot, too.

This is enough to hack-fix it, since BitOr still converts to 32bit:

Func _BitShift($iNum, $iShift)
    Return BitShift(BitOR($iNum, 0), $iShift)
EndFunc
Func _BitNot($iNum)
    Return BitNot(BitOR($iNum, 0))
EndFunc

Edited November 6, 2009 by ProgAndy

[Valik]

Ugh. Sorry guys. I'll revert this rubbish and go back to all the functions truncating at 32-bit until somebody who actually knows what the fuck they are doing can take a crack at better 64-bit support.

[trancexx]

Really ugly temporary hack (you'll go to hell if you use it):

ConsoleWrite(0xFFF & @CRLF)
ConsoleWrite(_BitShift(0xFFFFFFFF, 20) & @CRLF)
ConsoleWrite(0xFFFF & @CRLF)
ConsoleWrite(_BitShift(0xFFFFFFFF, 16) & @CRLF)
ConsoleWrite(0xFFFFF & @CRLF)
ConsoleWrite(_BitShift(0xFFFFFFFF, 12) & @CRLF)

Func _BitShift($iNum, $iShift)
    If ($iShift <= -32) Or ($iShift >= 32) Then Return SetError(1, 0, $iNum)
    If $iShift = 0 Then Return $iNum
    If $iShift < 0 Then
        ; negative shifts seem to work ok
        Return BitShift($iNum, $iShift)
    Else
        ; handle right shifts of negative numbers
        ; the magic: strip sign bit, shift, add back top bit in new position
        If $iNum < 0 Then Return BitOR(BitShift(BitAND($iNum, 0x7FFFFFFF), $iShift), 2 ^ (31 - $iShift))
    EndIf
    Return BitShift($iNum, $iShift)
EndFunc

And you are completely wrong

I believe you are actually reproducing the bug (and more). It's exactly signed/unsigned issue as ProgAndy showed.

[Beege]

_DebugSetup() seems to be blocking user input. Is that suppose to happen?

[wraithdu]

@trancexxx

Did you bother to try it? Did the examples produce the correct results? Then what's wrong about it?

Incidentally did you try ProgAndy's either?

ConsoleWrite(BitShift(BitOR(0xFFFFFFFF, 0), 16) & @CRLF)

Still produces -1 in 3.3.1.4 / 3.3.1.5.

Edited November 6, 2009 by wraithdu

[trancexx]

@trancexxx

Did you bother to try it? Did the examples produce the correct results? Then what's wrong about it?

Incidentally did you try ProgAndy's either?

ConsoleWrite(BitShift(BitOR(0xFFFFFFFF, 0), 16) & @CRLF)

Still produces -1 in 3.3.1.4 / 3.3.1.5.

What are you talking about?!? You lost me completely.

Btw, seems like you are confusing 'logical shift' and 'arithmetic shift'.

[wraithdu]

What are you talking about? I have no idea what that last comment is supposed to mean. The current BitShift() has a bug, my hack fixes it and produces the correct results, same as >> and << in C++. You wanna provide some example of what you're trying to say? I fail to see where I'm wrong. Don't just come out and say 'And you are completely wrong' without something to back it up.

Edited November 7, 2009 by wraithdu

[Valik]

Enough. It doesn't matter. I'll take a look and if AutoIt is broken I'll revert it back to the 3.3.0.0 behavior (Or Jon will if he beats me to checking on this). Debating this further is pointless.

[trancexx]

What are you talking about? I have no idea what that last comment is supposed to mean. The current BitShift() has a bug, my hack fixes it and produces the correct results, same as >> and << in C++. You wanna provide some example of what you're trying to say? I fail to see where I'm wrong. Don't just come out and say 'And you are completely wrong' without something to back it up.

Yes, sory if I offended you. I thought you would take it differently.

I'm talking about >>>

You are saying that the current (3.3.0.0) BitShift() is with bug?

edit: I see there were new happenings while I was typing.

Edited November 7, 2009 by trancexx

[wraithdu]

I'm not sure if this is exactly related, but I tried this on my x64 machine. It would explain what is going on with BitShift() if it is now internally using 64 bit numbers.

$s = DllStructCreate("ptr")
DllStructSetData($s, 1, 0xAFFFFFFF)
ConsoleWrite(DllStructGetData($s, 1) & @CRLF)

produces the output

0xFFFFFFFFAFFFFFFF

where I would expect it to produce

0x00000000AFFFFFFF

Edited November 7, 2009 by wraithdu

[Nutster]

Nutster,

Static is still not resizing arrays:

>Running:(3.3.1.5):C:\Program Files\AutoIt3\beta\autoit3.exe "C:\Program Files\AutoIt3\Beta\Examples\Helpfile\Static.au3"    
C:\Program Files\AutoIt3\Beta\Examples\Helpfile\Static.au3 (37) : ==> Cannot make existing variables static.:
Static $Values[$State + 1]
Static ^ ERROR
->12:23:13 AutoIT3.exe ended.rc:1

M23

I know. I have not submitted the update to this issue yet. I am working on it this weekend.

[Valik]

Advanced warning: Static will not be in the next beta going forward. It will be re-added after the beta starts again post next release.

In other words... don't start using it yet.