AutoIt doesn't store HEX as I expect ...

[TheRaph]

The Easiest way to explain my problem is to show this script ...

#include <WindowsConstants.au3>

;~ Global Const $WS_POPUP = 0x80000000
;~ declared in <WindowsConstants.au3>

Local $MY_WS_POPUP = 0x80000000
Local   $p = 0x0000000080000000

ConsoleWrite("P: " & $WS_POPUP & @CRLF)
ConsoleWrite("P: " & $MY_WS_POPUP & @CRLF)
ConsoleWrite("P: " & $p & @CRLF)

ConsoleWrite(@CRLF & "!---------------------" & @CRLF & @CRLF)

;~ Global Const $WS_CHILD = 0x40000000
;~ declared in <WindowsConstants.au3>

Local $MY_WS_CHILD = 0x40000000
Local   $c = 0x0000000040000000

ConsoleWrite("C: " & $WS_CHILD & @CRLF)
ConsoleWrite("C: " & $MY_WS_CHILD & @CRLF)
ConsoleWrite("C: " & $c & @CRLF)

Sleep(1000)

I expect this (all "popup" should be the same, and all "child" should be the same):

--> Press Ctrl+Alt+Break to Restart or Ctrl+Break to Stop
P: 2147483648
P: 2147483648
P: 2147483648

!---------------------

C: 1073741824
C: 1073741824
C: 1073741824
+>15:05:14 AutoIt3.exe ended.rc:0
+>15:05:14 AutoIt3Wrapper Finished.

Really, I got this:

--> Press Ctrl+Alt+Break to Restart or Ctrl+Break to Stop
P: -2147483648
P: -2147483648
P: 2147483648

!---------------------

C: 1073741824
C: 1073741824
C: 1073741824
+>15:05:14 AutoIt3.exe ended.rc:0
+>15:05:14 AutoIt3Wrapper Finished.

Why?

Why are the first 2 "P" negative?

Why did 0x40000000 mean the same as 0x0000000040000000, but 0x80000000 does not mean the same as 0x0000000080000000? !!

( I'm running AutoIt version 3.3.12)

I've try to "retranslate" -2147483648 into HEX (use calc.exe) and get FFFFFFFF80000000. It looks the same because first 4 bytes filled with 1 ... but why?

Thanks for help

Raph

Edited October 24, 2014 by TheRaph

[Melba23]

TheRaph,

AutoIt changed the way it looked at numbers a while ago and this change still causes problems until you get used to it. I am by no means expert in this areas, but I hope that this hobbyist explanation will suffice.

AutoIt stores numbers as signed 1nt32 and Int64 integers - so the difference between your 2 cases is that the one beginning "0x80..." is taken to be a negative Int32 which is indeed what you see in the console. When the value is read as an Int64 the "8" does not affect the "+/-" bits and so the number is regarded as positive. This amended script shows this in more detail:

#include <WindowsConstants.au3>

;~ Global Const $WS_POPUP = 0x80000000
;~ declared in <WindowsConstants.au3>

Local $MY_WS_POPUP = "80000000"
Local   $p = 0x0000000080000000

ConsoleWrite("P: " & $WS_POPUP & @CRLF)

ConsoleWrite("P: " & Dec($MY_WS_POPUP, 1) & @CRLF) ; Force Int32
ConsoleWrite("P: " & Dec($MY_WS_POPUP, 2) & @CRLF) ; Force Int64

ConsoleWrite("P: " & $p & @CRLF)

ConsoleWrite(@CRLF & "!---------------------" & @CRLF & @CRLF)

;~ Global Const $WS_CHILD = 0x40000000
;~ declared in <WindowsConstants.au3>

Local $MY_WS_CHILD = "40000000"
Local   $c = 0x0000000040000000

ConsoleWrite("C: " & $WS_CHILD & @CRLF)

ConsoleWrite("C: " & Dec($MY_WS_CHILD, 1) & @CRLF) ; Force Int32
ConsoleWrite("C: " & Dec($MY_WS_CHILD, 2) & @CRLF) ; Force Int64

ConsoleWrite("C: " & $c & @CRLF)

I hope that helps - as I said you are by no means alone in getting confused by this.

M23

[TheRaph]

Hi, thank u very much ...

That takes me to the right path.

Originally I got this by debugging style-arguments for "GUICreate()".

I think AutoIt "GUICreate" uses WinAPI "CreateWindowEx" ... as described in MSDN it needs an argument "dwStyle" var type "DWORD" and DWORD means 32bit unsigned int.

As far as I can see, in AutoIt there is no equivalent for "unsigned int" so the first bit of this 32bit var will be interpreted as indicator for positiv or negative instead of 2^32 ...

HWND WINAPI CreateWindowEx(
  _In_      DWORD dwExStyle,
  _In_opt_  LPCTSTR lpClassName,
  _In_opt_  LPCTSTR lpWindowName,
  _In_      DWORD dwStyle,
  _In_      int x,

  _In_      int y,
  _In_      int nWidth,
  _In_      int nHeight,
  _In_opt_  HWND hWndParent,
  _In_opt_  HMENU hMenu,
  _In_opt_  HINSTANCE hInstance,
  _In_opt_  LPVOID lpParam
);

Thank you again

Raph