Latest Beta

[wraithdu]

I just tested your example on a Win7 x64 machine with AutoIt 3.3.7.21, and all 4 functions were successful.

Edit:

BTW, INVALID_HANDLE_VALUE should be Ptr(-1). Be careful with implied data type conversions.

Edited December 2, 2011 by wraithdu

[KaFu]

Somehow installing / uninstalling / re-installing Autoit must have messed up my config, the script was always started with prod and not Beta ... now I did a fresh install and everything works fine. Thanks for testing and pointing out the potential issue with INVALID_HANDLE_VALUE !

Edited December 2, 2011 by KaFu

[KaFu]

Just in case anyone else ever searches for a way to read a FILETIME structure, here's a sample:

$tUINT64 = DllStructCreate("uint64")
    $tFILETIME = DllStructCreate("dword;dword", DllStructGetPtr($tUINT64))  
    $tWIN32_FIND_DATA = DllStructCreate("dword;STRUCT;dword;dword;ENDSTRUCT;STRUCT;dword;dword;ENDSTRUCT;STRUCT;dword;dword;ENDSTRUCT;dword;dword;dword;dword;wchar[260];wchar[14]")
    ; Call FindFirstFile / FindNextFile to fill structure
    DllStructSetData($tFILETIME, 1, DllStructGetData($tWIN32_FIND_DATA, 2))
    DllStructSetData($tFILETIME, 2, DllStructGetData($tWIN32_FIND_DATA, 3))
    $ftCreationTime = DllStructGetData($tUINT64, 1)

Realizing that these extra calls are needed I finally saw why Ascend4nt altered the WIN32_FIND_DATA structure in his excellent _FileFindEx UDF (latest version here) the way he did (yeah, took a while ). Adopting his method I've tried this with success :

$tWIN32_FIND_DATA = DllStructCreate("dword;STRUCT;align 4;uint64;ENDSTRUCT;STRUCT;align 4;uint64;ENDSTRUCT;STRUCT;align 4;uint64;ENDSTRUCT;dword;dword;dword;dword;wchar[260];wchar[14]")

_FileFindEx_2.zip

Edited December 2, 2011 by KaFu

[KaFu]

Hiho,

I've run into a number() problem, and maybe it's just related to underlying variable types (me )... I've read about a fix in the changelog for 3.3.7.20: "- Fixed #1519, #1694: Int() and Number() returning wrong."

Here's my test code:

$iNum = 3145728000
ConsoleWrite($iNum & @CRLF)
ConsoleWrite(Number($iNum) & @CRLF)
ConsoleWrite(String($iNum) & @CRLF)
ConsoleWrite(Number(String($iNum)) & @CRLF & @CRLF)
$iNum = "3145728000"
ConsoleWrite($iNum & @CRLF)
ConsoleWrite(Number($iNum) & @CRLF)
ConsoleWrite(String($iNum) & @CRLF)
ConsoleWrite(Number(String($iNum)) & @CRLF& @CRLF)
$iNum = -3145728000
ConsoleWrite($iNum & @CRLF)
ConsoleWrite(Number($iNum) & @CRLF)
ConsoleWrite(String($iNum) & @CRLF)
ConsoleWrite(Number(String($iNum)) & @CRLF& @CRLF)
$iNum = "-3145728000"
ConsoleWrite($iNum & @CRLF)
ConsoleWrite(Number($iNum) & @CRLF)
ConsoleWrite(String($iNum) & @CRLF)
ConsoleWrite(Number(String($iNum)) & @CRLF& @CRLF)

And here's the result for 3.3.7.21 compared to 3.3.6.1:

The result of 3.3.6.1 looks like what I would expect, but for 3.3.7.21 in some cases (marked green) it looks odd to me, esp. that this only seems to be true for positive values, negative values still look like I would expect them.

Best Regards

[trancexx]

Number() returns numeric (being primitive data type) representation of input data. If you pass numeric data then it doesn't do anything and returns what's passed. If you pass string, the function will do conversation for you. That's the difference.

What confuses you is that after the conversation it sizes the output depending on the size of the number. If it fits 32 bits then it's returned as 32bit integer, and as 64bit integer otherwise.

You will get second parameter for that (and similar) function which you will use to define how to do conversation.

Btw, you probably want to use Int() instead of Number().

Edited December 5, 2011 by trancexx

[KaFu]

Thanks for clarifying , goes into the direction I've assumed.

You will get second parameter for that (and similar) function which you will use to define how to do conversation.

Which is not yet documented / implemented and will be available with 3.3.8.0?

[jchd]

What confuses you is that after the conversation it sizes the output depending on the size of the number. If it fits 32 bits then it's returned as 32bit integer, and as 64bit integer otherwise.

In the case exposed it fit only mechanically but not semantically. The sign bit doesn't have the same meaning as the lower order bits. Shouldn't such conversions round trip?

[trancexx]

In the case exposed it fit only mechanically but not semantically. The sign bit doesn't have the same meaning as the lower order bits. Shouldn't such conversions round trip?

All bits are preserved. Everything else is matter of interpretation/representation, don't you agree?

@KaFu, it was implemented many cycles ago.

Edited December 5, 2011 by trancexx

[jchd]

Sorry I don't agree. It's a matter of consistency and legacy. All previous code will need careful review to ensure "interpretation" won't change with the new version and that needs proving invariants that were previously irrelevant.

Then it gets worse if I write such a value in a file or a database. I'm not going to retrieve it verbatim and that can be a major issue.

[trancexx]

You don't have to be sorry and you are right about consistency.

That's why the code was changed. It was inconsistent mess before.

[jchd]

I'm well aware of the previous issues (not at the code level of course). Anyway how do you address the new store X -- retrieve Y problem?

[Valik]

I'm well aware of the previous issues (not at the code level of course). Anyway how do you address the new store X -- retrieve Y problem?

From the changelog for 3.3.7.22:

- Changed: Dec(), Int(), Number() have second optional parameter defining non-default behavior.

[jchd]

I knew you always have a secret weapon ready or ready to get ready!

Thanks trancexx + Valik (hope you're in better shape!).

[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.22 (7th December, 2011 (Beta)

AutoIt:

- Added #2042: @OSVersion returns "Win_8" on Windows 8.

- Changed: Dec(), Int(), Number() have second optional parameter defining non-default behavior.

- Changed: Hex() detects doubles internally and processes them respecting binary format.

- Changed: New visual style for the documetnation.

UDFs:

- Added: _WinAPI_StringLenA() and _WinAPI_StringLenW() functions.

- Added: _WinAPI_DuplicateHandle() function.

- Added: _Security__CreateProcessWithToken(), _Security__DuplicateTokenEx and _Security__SetTokenInformation functions.

- Added #1925: $WS_EX_LAYOUTRTL control style to the documentation.

- Added #2049: Missing windows message codes to WindowsConstants.au3.

- Fixed #1777: Issues with Security.au3.

- Fixed #2055: replaced DllStructGetPtr with "struct*" throughout UDFs.

- Fixed #2048: Windows constants $WM_RBUTTONDBLCLK and $WM_MBUTTONDBLCLK were named incorrectly.

- Fixed #2034: _GUICtrlMenu_AppendMenu dllcall type set wrong.

- Fixed #2060: Various documentation errors.

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.

[guinness]

Moved to appropriate thread.

Edited December 7, 2011 by guinness

[Valik]

Cough wrong thread jackass cough.

[guinness]

Sorry, mistakes rarely happen but when they do I know how to make a fool of myself. Moved to the appropriate thread.

Edited December 7, 2011 by guinness

[jaberwacky]

I see this error when I run a script that uses the _Singleton function:

C:Program Files (x86)AutoIt3BetaIncludeMisc.au3 (491) : ==> Variable used without being declared.:
Local $handle = DllCall("kernel32.dll", "handle", "CreateMutexW", "struct*", $tSecurityAttributes, "bool", 1, "wstr", $sOccurenceName)
Local $handle = DllCall("kernel32.dll", "handle", "CreateMutexW", "struct*", ^ ERROR

Win 7 x64

Latest Beta

Edited December 8, 2011 by LaCastiglione

[wraithdu]

That raises an interesting question... is there a way to use struct* and still pass a null pointer? The old version of _Singleton allowed for a null pointer as that parameter.

Either way, that function is still broken when not using flag 2.

Edited December 8, 2011 by wraithdu

[Valik]

If I wrote a piece of code and you decide to change it... you need to pay attention. I write code that takes scope into account. This was a case where somebody didn't notice the scope a variable needed to be in.

Passing an non-DllStruct variable as a "struct*" should result in it being treated as a NULL pointer. That's my expectation at any rate.