Latest Beta

Valik · February 4, 2012

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)

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:

None so far.

Report issues here.

Download here.

guinness · February 5, 2012

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 · February 5, 2012

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

Richard Robertson · February 5, 2012

Null is an object reference value for COM I assume.

ProgAndy · February 5, 2012

"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 February 5, 2012 by ProgAndy

AdmiralAlkex · February 5, 2012

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 · February 5, 2012

Helpfile explains it good.

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

UEZ · February 5, 2012

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 February 5, 2012 by UEZ

jaberwacky · February 5, 2012

Can somebody confirm that behaviour?

Happens ot me too. Windows 7 x64

Xenobiologist · February 6, 2012

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 February 6, 2012 by Xenobiologist

trancexx · February 6, 2012

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 · February 6, 2012

Thanks for clarification.

(Please move the post to somewhere else, avoiding a discussion here)

wraithdu · February 6, 2012

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

Valik · February 6, 2012

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 February 6, 2012 by Valik
Re-worded poorly worded sentence.

trancexx · February 7, 2012

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 February 7, 2012 by trancexx

trancexx · February 7, 2012

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 · February 8, 2012

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 · February 8, 2012

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?

jaberwacky · February 8, 2012

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

trancexx · February 8, 2012

It shows -1 on my machine.

Your machine is fine.

Sign In

Latest Beta

Recommended Posts

Valik

Top Posters In This Topic

Top Posters In This Topic

Popular Posts

Valik

Valik

Valik

guinness

Yashied

Richard Robertson

ProgAndy

AdmiralAlkex

ProgAndy

UEZ

jaberwacky

Xenobiologist

trancexx

Xenobiologist

wraithdu

Valik

trancexx

trancexx

wraithdu

trancexx

jaberwacky

trancexx

Create an account or sign in to comment

Create an account

Sign in

Recently Browsing 0 members

Browse

AutoIt Resources

Release

Beta