182 replies to this topic

[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.9.0 (4th February, 2012) (Beta)

Spoiler

AutoIt:
- Added: Interpreter accepts 64bit hex numbers.
- Added: Keyword Null.
- Added #488: Third parameter for ObjGet() function to specify object instance.

- Changed: upx.exe from 3.07 -> 3.08.
- Changed: ReDim works on arrays declared as static.
- Changed: Run-time errors on objects no longer fatal (execution of the script is not halted).

- Fixed #2067: -2147483648 not stored as int32.
- Fixed #2003: ProcessWaitClose() using too much CPU.
- Fixed #2076: COM VARIANT not correctly set for boolean True.
- Fixed #2015: DllCallbackRegister() mangles floating point numbers under x64.
- Fixed: x64 DllCall not setting double type parameters correctly.
- Fixed: DllCallbackRegister() not returning floating point types correctly.
- Fixed: Different issues with Static keyword.
- Fixed #2078: Error in com expression.
- Fixed #2073: Unexpected termination with ContinueLoop.
- Fixed #1485: Unexpected termination with ContinueCase.
- Fixed: Crash in ObjEvent() for byref object parameters.
- Fixed #2068: Repeated calls to Acos() no longer produce strange results. NOTE: This fix increases the size of AutoIt by approximately 60KB.
- Fixed: ObjGet() fails validating class identifier properly when first parameter for the function is specified.
- Fixed #2111: RunAs() could fail even if a user had the correct permissions to use it.

UDFs:
- Added: _WinAPI_GetProcAddress() function.

- Fixed #2077: hwnd safety check in _GUICtrlRichEdit_Create()
- Fixed #2088: _ArrayDisplay not handling Default parameters correctly.
- Fixed #2112: "Report Log Window" unresponsive when the script is closed.
- Fixed: _GUICtrlRichEdit_* documentation error return codes.
- Fixed #1970: _FTP_ListToArray() fails to retrieve Dir or File only.

Au3Check:
- Fixed #2113: Object's properties in names of keywords treated as keywords.
- Added: Generating error for hex numbers longer than 16 characters.
- Changed: Message case changed to support SciTE inline errors.
- Changed: An error is now generated for non-supported file encodings (Previous behavior was to silently pass the script).

Au3Record:
- Fixed #2083: There is no longer an error about a missing DLL.

The following changes are script breaking changes:

Spoiler

None so far.

Report issues here.
Download here.

[guinness]

Looks alright so far, but I gave Au3Record a quick fire for the first time ever and it seems when the script is saved WinWaitActivate is displaying as _WinWaitActivate instead. I'll post a bug report but wanted to make it clear I don't use Au3Record.

[Yashied]

"Null" is a true zero (INT32) or not?

[Richard Robertson]

Null is an object reference value for COM I assume.

[ProgAndy]

"Null" is a true zero (INT32) or not?

Null is a true NULL stored as a keyword just like Default, True and False. It differs from Nullpointer, Integer 0, Empty String. In a COM_VARIANT it should be represented as VT_NULL, maybe VT_EMPTY. If you convert Null to Integer, a zero should be the result

Edited by ProgAndy, 05 February 2012 - 11:36 AM.

[AdmiralAlkex]

Helpfile explains it good.

Null evaluates only to Null, still in mathematical operations this keyword has value of 0, and as string it has no value (empty string).
COM method will receive Null as VT_NULL VARIANT. DllCall's wstr and str types will be set to NULL (pointers).

[ProgAndy]

Helpfile explains it good.

Yes, finally there is no need for If $string="" Then $dllcalltype = "ptr" anymore

[UEZ]

When I start AutoIt Windows Screenshooter with this beta (3.3.90) and hovering buttons then the buttons disappearing and coming back again.

Currently I don't know the reason.

Can somebody confirm that behaviour?

Tested on Win7 x64.

Br,
UEZ

Edited by UEZ, 05 February 2012 - 07:29 PM.

[jaberwocky6669]

Can somebody confirm that behaviour?

Happens ot me too. Windows 7 x64

[Xenobiologist]

Do I miss a change in syntax? What is wrong with this piece of code? Works in 3.3.8.1 but not in 3.3.9.0

ConsoleWrite(_bootTime() & @LF)
Func _bootTime()
Local $objWMIService = ObjGet('winmgmts:{impersonationLevel=impersonate}!.rootcimv2', '')
ConsoleWrite($objWMIService & ' ' & @error & @LF)
ConsoleWrite(IsObj($objWMIService) & ' Yes/no?' & @LF)
Local $colSettings = $objWMIService.ExecQuery('Select * from Win32_OperatingSystem')
For $objOperatingSystem In $colSettings
Next
;~  WMIDateStringToDate($objOperatingSystem.InstallDate))
Return WMIDateStringToDate($objOperatingSystem.LastBootUpTime)
EndFunc   ;==>_bootTime
Func WMIDateStringToDate($dtmDate)
Return (StringMid($dtmDate, 7, 2) & '.' & _
   StringMid($dtmDate, 5, 2) & '.' & StringLeft($dtmDate, 4) _
    & ' ' & StringMid($dtmDate, 9, 2) & ':' & StringMid($dtmDate, 11, 2) & ':' & StringMid($dtmDate, 13, 2))
EndFunc   ;==>WMIDateStringToDate

As usual, if this is not the thread for asking that, then please move/delete it without a big drama. Thanks!

>Running:(3.3.9.0):C:ProgrammeAutoIt3betaautoit3.exe "C:AutoitForumTests_getBootTime.au3"  
-2147221005
0 Yes/no?
"C:AutoitForumTests_getBootTime.au3" (8) : ==> Error in expression.:
Local $colSettings = $objWMIService.ExecQuery('Select * from Win32_OperatingSystem')
Local $colSettings = ^ ERROR
->10:38:12 AutoIT3.exe ended.rc:1

By the way, there is a mistake in the helpfile ObjGet : Returns empty sring and sets @error.
Mega

Edited by Xenobiologist, 06 February 2012 - 09:54 AM.

[trancexx]

You missed nothing (except the thread yes). ObjGet was rewritten, but it wasn't finished. It's was already reported to me.
Next beta will have complete code, actually already has.
That code shows another problem, printed error should have been 'Variable must be of type "Object"'.

[Xenobiologist]

Thanks for clarification.
(Please move the post to somewhere else, avoiding a discussion here)

[wraithdu]

So is COM broken in this beta then? Just ObjGet? Just ObjGet in certain situations? Can you clarify that a bit? Thanks!

[Valik]

I've moved the posts here (and one by guinness) as well. While he and I did briefly go off-topic discussing music in the other thread it is about upcoming betas (hence the name). That is, things that may need to be done before a beta comes out, what's holding up a release (my rage post at security structures), et cetera. Discussions on released betas (and whether or not the broken things are fixed) still goes here. Of course if you guys wish to bring something up without the public getting in the way then make a new thread in the MVP forum.

Edited by Valik, 06 February 2012 - 03:50 PM.
Re-worded poorly worded sentence.

[trancexx]

When I start AutoIt Windows Screenshooter with this beta (3.3.90) and hovering buttons then the buttons disappearing and coming back again.

Currently I don't know the reason.

Can somebody confirm that behaviour?

Tested on Win7 x64.

Br,
UEZ

It's x86 callback. Currently AutoIt pushes data onto FPU stack regardless of the type of return. This is opposite of what it did before.
The problem with the code before was that float and double types weren't returned by callback functions at all.

Why this causes problems to windows hooks is not clear to me but apparently it does. Why FPU stack would affect procedures that don't rely on it? Maybe it's even some of our GUI code that does something that ACos() did. I hope not.
Nevertheless, the code is overdoing now.

As for your script... do something with it. For example, what's with that DEP thing? That's lame.

Edited by trancexx, 07 February 2012 - 12:58 PM.

[trancexx]

So is COM broken in this beta then? Just ObjGet? Just ObjGet in certain situations? Can you clarify that a bit? Thanks!

ObjGet with non-file monikers doesn't work in this beta. Any other COM code that worked before should work now too.

[wraithdu]

Nevertheless, the code is overdoing now.

I'm not sure what you mean by that... You've found the problem and it will be fixed in next beta?

[trancexx]

I'm not sure what you mean by that... You've found the problem and it will be fixed in next beta?

Yes that's it.

Anyone noticed that this is possible now:

$i64bitNum = 0xFFFFFFFFFFFFFFFF
ConsoleWrite($i64bitNum & @CRLF)

I'm saying that because functions for bitwise operations should follow the changes with special care for backward compatibility. That said, functions that could be problematic are BitShift() and BitRotate().
wraithdu you had a stub or two into bitwise operations. Any thoughts on this?
Or anyone else maybe? What are the expectations?

[jaberwocky6669]

It shows -1 on my machine. The msb is set so that makes it negative right?

[trancexx]

It shows -1 on my machine.

Your machine is fine.