Latest Beta

[trancexx]

Forget about strings and signs. Code is changed on more fundamental level.

I'm about to commit the changes and I would love to have it tested by interested people, to see if that's what's wanted.

The level of my English is not that advanced for me to be able to give description for new behavior that wouldn't be so freaking complicated. I tried, and then reading after 30 minutes I found my self not being able to understand what I wrote, lol.

[trancexx]

But before I commit anything, could someone say what should be the result of this:

$sHex = "80000000"
$iHex = Dec($sHex)
ConsoleWrite($iHex & @CRLF)
ConsoleWrite(VarGetType($iHex) & @CRLF)

This is very important because if I would introduce inconsistency with the changes then I won't change anything at all. I need explanation on "what" and "why".

edit:

To make it more clear to what I'm aiming, run this in your head and post the results:

$sHex = "80000000"
$iHex = Dec($sHex)
ConsoleWrite($iHex & @CRLF)
ConsoleWrite(VarGetType($iHex) & @CRLF)

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

$iHexNum = 0x80000000
ConsoleWrite($iHexNum & @CRLF)
ConsoleWrite(VarGetType($iHexNum) & @CRLF)

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

$iNum = Number($iHexNum)
ConsoleWrite($iNum & @CRLF)
ConsoleWrite(VarGetType($iNum) & @CRLF)

Edited December 9, 2011 by trancexx

[jchd]

Converting a hex string is a situation where "fitting the bits" provided _is_ expected. I fully agree in this case.

For me the result I get (with x86) are fine and match the help file description without any ambiguity.

-2147483648

Int32

3.3.6.1 says "The function only works with numbers that fit in a 32 bit signed integer (-2147483648 to 2147483647)"

So this is consistent with old behavior.

3.3.7.22 says "Default behavior is that input string is treated as integer. In this case if the result fits 32bit, it's returned as 32bit integer and if not it's returned as 64bit integer. Both signed."

I see this as consistent as well, because by giving a 32-bit hex input to be converted as a signed int, this is the result you should naturally expect.

Sign-extend of 0x80000000 to 64-bit gives that value.

More worrysome is the case of "0000000080000000"

which also gets converted to the same _negative_ value. I feel that providing 64-bit input should cause a verbatim map to the resulting 64-bit value.

Making Dec("FFFFFFFF80000000") = Dec("0000000080000000") doesn't look right at any rate.

What do other think?

Edit:

Following your edit which I saw only afterwards, what I currently get is what I feel should be expected

-2147483648

Int32

--------------------------

-2147483648

Int32

--------------------------

-2147483648

Int32

32-bit hex --> 32-bit signed variant verbatim sounds fine as we don't have a native unsigned 32-bit container. Yes, we have one in Ptr() on an x86 machine but this is non-portable.

Manipulation of hex strings, pointers and such are rather technical, hence we can expect users to be aware or at least able to understand about sign-extension of 32 to 64 values (or lack of) and relating details. Also, those "tech users" can also understand that hex values 0x01234567 are limited to 32-bit and may have to use conversion with Dec("0123456789ABCDEF") to get into 64-bit range, which should be made to work.

It's nonetheless important to make meanings and behavior clear in the docs. Thats where I feel it would be clearer to say that when converting a decimal string, the value is converted to give the same value in integral type of suitable size, while when converting hex input, the bits are mapped verbatim into an integral type of same size: providing 32-bit hex loads a 32-bit INT32, providing 64-bit hex loads a 64-bit INT64, both signed.

Edited December 9, 2011 by jchd

[jaberwacky]

Shouldn't it be this?

2147483648
Int64
--------------------------
2147483648
Int64
--------------------------
2147483648
Int64

Because -2147483648 is 0xffff ffff 8000 0000 and 2147483648 is 0x8000 0000 , right?

[Valik]

I agree with what jchd says.

LaCastiglione, you are mixing 64-bit and 32-bit types. The input 0x80000000 is 32-bits, not 64. If it were 0x0000000080000000 then you would be correct. But it's not.

[jchd]

@Valik,

How difficult would it be to allow 64-bit hex literal values 0x*************** just for completing the range as this seems still missing? Maybe it won't be of common use but it looks like it's the only option we don't have. I realize that it will need adjusting Au3Check and Tidy and possibly something else but that should probably not be very hard.

I'm still bounded to x86 for now and can't test x64 pointer arithmetic. I guess they work the same as for x86, pointer diff returning a Ptr variant. In the rare situation where the need to compare or order large x64 ptr or ptrdiffs, I imagine the only way would be to compare their hex representations but that is an exceptional need (unless I miss something).

Also since Number auto-sizes by default, can it be made to automagically convert to Double those strings of integers that exceed the signed 64-bit maxint values, which is what it currently returns in such case? That also seems a rare case of real-world use, but it would make the default conversion essentially fail-proof. Meaningful digits strings exceeding Double capacity are just plain crazy.

[Valik]

I defer these questions to trancexx since she is more familiar with the code now. I do not have issue with 64-bit hex digits being supported, however, it should probably wait until after 3.3.8. The last time somebody tried to add support for that AutoIt took a big thick one up the pooper and Jon and I were not exactly thrilled. While trancexx is a far better programmer than the person who did that... still, better safe than sorry. Also no lube.

[jchd]

I see. Of course there's little need to rush for that and I guess you and trancexx have more important things to do/check for the next release.

Thanks for feedback anyway.

[KaFu]

I'm not sure what to make of this one , is it a bug or is it just related to the new way of how objects work now? This code works fine with 3.3.6.1 but throws an error with the current Beta.

; $tagNMLVCUSTOMDRAW
; Local $iItem = DllStructGetData($tCustDraw, "dwItemSpec") => DWORD_PTR
$i = 1
$t = DllStructCreate("DWORD_PTR")
DllStructSetData($t, 1, $i)
ConsoleWrite(VarGetType($i) & @TAB & VarGetType(DllStructGetData($t, 1)) & @CRLF & @CRLF)
$oMyError = ObjEvent("AutoIt.Error", "MyErrFunc")
$oDict = ObjCreate("Scripting.Dictionary")
ConsoleWrite($oDict.Exists(1) & @CRLF)
ConsoleWrite($oDict.Exists(DllStructGetData($t, 1)) & @CRLF)
Func MyErrFunc()
ConsoleWrite("! We intercepted a COM Error !" & @CRLF & "=======================" & @CRLF & _
   "err.description is: " & @TAB & $oMyError.description & @CRLF & _
   "err.windescription:" & @TAB & $oMyError.windescription & @CRLF & _
   "err.number is: " & @TAB & Hex($oMyError.number, 8) & @CRLF & _
   "err.lastdllerror is: " & @TAB & $oMyError.lastdllerror & @CRLF & _
   "err.scriptline is: " & @TAB & $oMyError.scriptline & @CRLF & _
   "err.source is: " & @TAB & $oMyError.source & @CRLF & _
   "err.helpfile is: " & @TAB & $oMyError.helpfile & @CRLF & _
   "err.helpcontext is: " & @TAB & $oMyError.helpcontext & @CRLF & @CRLF)
EndFunc   ;==>MyErrFunc

Edit: Btw, I would have expected DWORD_PTR to be of the type int32 on my x86 system and not int64.

Edited December 12, 2011 by KaFu

[JFX]

From remarks of Hex function:

Numbers passed as non-integers (those with decimal separator or exponent) are processed as doubles.

Okay, but how are doubles processed with latest Beta?

$iNum = Number(2.5 * 4)
ConsoleWrite($iNum & @CRLF)
ConsoleWrite(Hex($iNum) & @CRLF)
ConsoleWrite(VarGetType($iNum) & @CRLF)

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

$iNum = Number(10)
ConsoleWrite($iNum & @CRLF)
ConsoleWrite(Hex($iNum) & @CRLF)
ConsoleWrite(VarGetType($iNum) & @CRLF)

[trancexx]

I'm not sure what to make of this one , is it a bug or is it just related to the new way of how objects work now? This code works fine with 3.3.6.1 but throws an error with the current Beta.

; $tagNMLVCUSTOMDRAW
; Local $iItem = DllStructGetData($tCustDraw, "dwItemSpec") => DWORD_PTR
$i = 1
$t = DllStructCreate("DWORD_PTR")
DllStructSetData($t, 1, $i)
ConsoleWrite(VarGetType($i) & @TAB & VarGetType(DllStructGetData($t, 1)) & @CRLF & @CRLF)
$oMyError = ObjEvent("AutoIt.Error", "MyErrFunc")
$oDict = ObjCreate("Scripting.Dictionary")
ConsoleWrite($oDict.Exists(1) & @CRLF)
ConsoleWrite($oDict.Exists(DllStructGetData($t, 1)) & @CRLF)
Func MyErrFunc()
ConsoleWrite("! We intercepted a COM Error !" & @CRLF & "=======================" & @CRLF & _
   "err.description is: " & @TAB & $oMyError.description & @CRLF & _
   "err.windescription:" & @TAB & $oMyError.windescription & @CRLF & _
   "err.number is: " & @TAB & Hex($oMyError.number, 8) & @CRLF & _
   "err.lastdllerror is: " & @TAB & $oMyError.lastdllerror & @CRLF & _
   "err.scriptline is: " & @TAB & $oMyError.scriptline & @CRLF & _
   "err.source is: " & @TAB & $oMyError.source & @CRLF & _
   "err.helpfile is: " & @TAB & $oMyError.helpfile & @CRLF & _
   "err.helpcontext is: " & @TAB & $oMyError.helpcontext & @CRLF & @CRLF)
EndFunc   ;==>MyErrFunc

That's not related to AutoIt. That code would/should error out in any language. Exists method tend to produce error for int64.

The fact that it's not crashing* in older versions of AutoIt means that they weren't passing int64 when you wanted that.

edit:

* - the error is DISP_E_EXCEPTION

Edited December 12, 2011 by trancexx

[trancexx]

From remarks of Hex function:

Okay, but how are doubles processed with latest Beta?

$iNum = Number(2.5 * 4)
ConsoleWrite($iNum & @CRLF)
ConsoleWrite(Hex($iNum) & @CRLF)
ConsoleWrite(VarGetType($iNum) & @CRLF)

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

$iNum = Number(10)
ConsoleWrite($iNum & @CRLF)
ConsoleWrite(Hex($iNum) & @CRLF)
ConsoleWrite(VarGetType($iNum) & @CRLF)

What would you expect to be printed?

[JFX]

What would you expect to be printed?

I would expect the old output from 3.3.6.1, because 10 = 10.

10

0000000A

Double

--------------------------

10

0000000A

Int32

[KaFu]

That's not related to AutoIt. That code would/should error out in any language. Exists method tend to produce error for int64. The fact that it's not crashing* in older versions of AutoIt means that they weren't passing int64 when you wanted that. edit: * - the error is DISP_E_EXCEPTION

I've assumed something along that line... but why is the DWORD_PTR of the type int64 on my x86 system?

[trancexx]

I've assumed something along that line... but why is the DWORD_PTR of the type int64 on my x86 system?

Eh, what you want me to say?

We don't have unsigned 32bit integer as primitive data type, in all scenarios it will end up turned to something else.

[trancexx]

I would expect the old output from 3.3.6.1, because 10 = 10.

10

0000000A

Double

--------------------------

10

0000000A

Int32

That first number is stored in your computer's memory as 4024000000000000 hex, the other number is stored as 0000000A hex.

[JFX]

That first number is stored in your computer's memory as 4024000000000000 hex, the other number is stored as 0000000A hex.

Okay, thanks for explanation! Think it's unusual for Autoit3, but i know how to fix my code now.

[jchd]

We don't have unsigned 32bit integer as primitive data type, in all scenarios it will end up turned to something else.

But we do have Ptr variant which should be fine for that use (x86 or x64), don't we?

[Valik]

DWORD_PTR should always be 32-bits on x86, no exceptions. That's the point of it's existence. I'm not sure why it would ever be 64-bits.

[Valik]

Special Note: This is an official beta release but it is not digitally signed. Only Jon has the certificate used for digital signatures and the last time I checked I was not Jon.

3.3.7.23 (12th December, 2011) (Beta)

AutoIt:

- Changed: Dec(), Int() and Number() default conversion behavior improved.

- Changed: Adjustments to the documentation visual style.

- Changed: Various documentation and example fixes.

The following changes are script breaking changes:

AutoIt:

• ObjName() has had a number of bug fixes and changes that may affect data returned. Built-in UDFs have been changed to accomodate this but custom scripts may need to be edited.
• ObjEvent() AutoIt.Error objects no longer have Raise() or Clear() methods and the properties are read-only.
• Int() and Hex() no longer set @error.
• COM methods now require parenthesis so the language can internally detect properties versus methods easier.

Important Note: This version contains a change to the visual style used in the documentation. We need feedback on this style. Please leave all feedback (both positive and negative) in

Note: For all you whiny bitches, COM speed is almost as fast as 3.3.6.1. Thank all of you for the little faith you show in us.

Report issues here.

Download here.