Latest Beta

[jvanegmond]

"Added #1270: GuiSetIcon() now finds suitable large and small icons."

Can somebody please elaborate on that?

Stab in the dark:

In previous versions GUISetIcon only found suitable 32x32 icons in an icon library, now it also sees 16x16 and 64x64 (etc) icons.

Edit: typo

Edited November 23, 2009 by Manadar

[Valik]

Thanks for the clarification. Is there a way to force an unsigned BitShift operation? C++ defaults to an unsigned operation when a number is given as an argument:

0xffffffff >> 16 = 0x0000ffff

Not at this time. You'll essentially have to do it yourself by taking into consideration the sign bit.

[Jon]

Stab in the dark:

In previous versions GUISetIcon only found suitable 32x32 icons in an icon library, now it also sees 16x16 and 64x64 (etc) icons.

Edit: typo

#741423

[Nutster]

Thanks for the clarification. Is there a way to force an unsigned BitShift operation? C++ defaults to an unsigned operation when a number is given as an argument:

0xffffffff >> 16 = 0x0000ffff

You could try (untested)

Func UnsignedBitShift(const $value, const $bitshift)
   Dim $retval

    If $bitshift > 0 Then
        $retval = $value << $bitshift
    ElseIf $bitshift < 0 Then
        $retval = BitAnd($value, 0x7fffffff) >> (-$bitshift)              ; Strip the sign bit and then bit-shift.
        If $value < 0 Then $retval = BitOR($retval, 1 << (31-$bitshift))  ; Introduce the removed sign bit
    Else    ; $bitshift = 0
        $retval = $value
    EndIf
    Return $retval
EndFunc

Msgbox(0, "Bitshift test", UnsignedBitShift(0xffffffff, -16))

[Gordon J. Tyler]

StringSplit() without the optional flag is not returning an array 100% of the time.

I cannot figure out what I am doing to make it not work.

I can run the same code several times and the script will abort once with a message that I was trying to access a non-array.

I'm going to put a wrapper around all my calls to StringSplit() to see if I can get you more information.

In the meantime, maybe someone can review the code and see if maybe the default parameter is getting clobbered or something?

I've already changed a lot of code to use some of the new features in InetGet() so I can't go back now.

I have to code freeze by Dec 4th and it doesn't seem we'll be out of Beta by then.

Ready for suggestions.

[Gordon J. Tyler]

StringSplit() without the optional flag is not returning an array 100% of the time.

I cannot figure out what I am doing to make it not work.

I can run the same code several times and the script will abort once with a message that I was trying to access a non-array.

I'm going to put a wrapper around all my calls to StringSplit() to see if I can get you more information.

In the meantime, maybe someone can review the code and see if maybe the default parameter is getting clobbered or something?

I've already changed a lot of code to use some of the new features in InetGet() so I can't go back now.

I have to code freeze by Dec 4th and it doesn't seem we'll be out of Beta by then.

Ready for suggestions.

I was able to isolate the issue and perhaps it should be listed in script breaking news.

It has nothing to do with StringSplit()

If your scripts call _Date_Time_GetTimeZoneInformation() and expects to always get an array back, you are in trouble.

Here's my code that crashes:

Func net_getCurrentTimeZoneOffset()
    Local $TimeBias = _Date_Time_GetTimeZoneInformation()
    Switch $TimeBias[0]
    Case 0      ;; DST not used
        Return Number($TimeBias[1])
    Case 1      ;; standard time
        Return Number($TimeBias[1]) + Number($TimeBias[4])
    Case 2      ;; daylight time
        Return Number($TimeBias[1]) + Number($TimeBias[7])
    EndSwitch
    Return 0
EndFunc

It's because _Date_Time_GetTimeZoneInformation() has changed from the production version to the Beta version:

Production:

Func _Date_Time_GetTimeZoneInformation()
    Local $tTimeZone, $aInfo[8], $aResult

    $tTimeZone = DllStructCreate($tagTIME_ZONE_INFORMATION)
    $aResult = DllCall("Kernel32.dll", "int", "GetTimeZoneInformation", "ptr", DllStructGetPtr($tTimeZone))
    $aInfo[0] = $aResult[0]
    $aInfo[1] = DllStructGetData($tTimeZone, "Bias")
    $aInfo[2] = _WinAPI_WideCharToMultiByte(DllStructGetPtr($tTimeZone, "StdName"))
    $aInfo[3] = _Date_Time_CloneSystemTime(DllStructGetPtr($tTimeZone, "StdDate"))
    $aInfo[4] = DllStructGetData($tTimeZone, "StdBias")
    $aInfo[5] = _WinAPI_WideCharToMultiByte(DllStructGetPtr($tTimeZone, "DayName"))
    $aInfo[6] = _Date_Time_CloneSystemTime(DllStructGetPtr($tTimeZone, "DayDate"))
    $aInfo[7] = DllStructGetData($tTimeZone, "DayBias")
    Return $aInfo
EndFunc   ;==>_Date_Time_GetTimeZoneInformation

Beta:

Func _Date_Time_GetTimeZoneInformation()
    Local $tTimeZone = DllStructCreate($tagTIME_ZONE_INFORMATION)
    Local $aResult = DllCall("kernel32.dll", "dword", "GetTimeZoneInformation", "ptr", DllStructGetPtr($tTimeZone))
    If @error Or $aResult[0] = -1 Then Return SetError(@error, @extended, 0)   ;; <<< NEW LINE OF CODE

    Local $aInfo[8]
    $aInfo[0] = $aResult[0]
    $aInfo[1] = DllStructGetData($tTimeZone, "Bias")
    $aInfo[2] = _WinAPI_WideCharToMultiByte(DllStructGetPtr($tTimeZone, "StdName"))
    $aInfo[3] = __Date_Time_CloneSystemTime(DllStructGetPtr($tTimeZone, "StdDate"))
    $aInfo[4] = DllStructGetData($tTimeZone, "StdBias")
    $aInfo[5] = _WinAPI_WideCharToMultiByte(DllStructGetPtr($tTimeZone, "DayName"))
    $aInfo[6] = __Date_Time_CloneSystemTime(DllStructGetPtr($tTimeZone, "DayDate"))
    $aInfo[7] = DllStructGetData($tTimeZone, "DayBias")
    Return $aInfo
EndFunc   ;==>_Date_Time_GetTimeZoneInformation

No big deal, just need to check for @error now

The Beta UDF documention for the function does not mention that an array may not be returned.

At the very least, that needs to be changed.

Edited November 25, 2009 by Gordon J. Tyler

[Valik]

Sigh. This is what happens when I try to add proper error checking to code that people couldn't be bothered to write error checking code for to begin with. It is neither safe nor sane for the code to return an array populated with garbage. It should have always returned a non-array value on error.

[wraithdu]

You could try (untested)

Thanks, but I've already posted a working solution in the Example forum. Besides...I think you were somewhere between AutoIt and C++ when you wrote that

[Nutster]

Thanks, but I've already posted a working solution in the Example forum. Besides...I think you were somewhere between AutoIt and C++ when you wrote that

Actually, I was developing a database-interactive website at the time, so I was between Javascript and Perl. I will check out your work-around.

[wraithdu]

Not at this time. You'll essentially have to do it yourself by taking into consideration the sign bit.

Considering this, wouldn't this be a prudent change to the _WinAPI_HiWord() function?

Func _WinAPI_HiWord($iLong)
    Return BitAND(0xFFFF, BitShift($iLong, 16))
EndFunc   ;==>_WinAPI_HiWord

;==========
ConsoleWrite(Hex(_WinAPI_HiWord(0xABCDEEEE)) & @CRLF)

Edited November 27, 2009 by wraithdu

[Gordon J. Tyler]

Sigh. This is what happens when I try to add proper error checking to code that people couldn't be bothered to write error checking code for to begin with. It is neither safe nor sane for the code to return an array populated with garbage. It should have always returned a non-array value on error.

I agree - just would have been nice to see a line item in the beta release notes about the change.

Turns out that the UDF functions _SetDate() and _SetTime() also need to be fixed - not just my code.

We found that _Date_Time_SetLocalTime() will sometimes return @error and those two functions call it but do not check for @error before referencing the array.

I have opened a bug on this and patched my Date.au3 file.

[Gordon J. Tyler]

Is there anyway to get the actually HTTP return code when InetGet() or InetRead() fail?

I always see @error set to 13 and mostly @extended set to 0

Would really like to be able to isolate our errors.

[Valik]

No, there's not nor will there be. Not all failures are at the HTTP level. Not all failures are at the API level. It would be a huge cluster-fuck to document what @error and @extended mean under which conditions in order to always return relevant error information. I can tell you that InetGet() is failing because the site is NOT returning the HTTP success code 200.

[Gordon J. Tyler]

No, there's not nor will there be. Not all failures are at the HTTP level. Not all failures are at the API level. It would be a huge cluster-fuck to document what @error and @extended mean under which conditions in order to always return relevant error information. I can tell you that InetGet() is failing because the site is NOT returning the HTTP success code 200.

Okay then, maybe you can suggest an alternative method for at least one task that I am working on...

I want to know if a device at a given IP address is running an HTTP server on a specific port.

I don't need to get any data from it, just need to know if the server is running in order to identify the device.

Would you just suggest using the TCPConnect() function?

I would want to be able to set a short timeout (5-10 secs) since hte device is on the LAN

[Valik]

Yes, I would just use TCP functions. If you connect then send a simple HTTP request and see if you get an HTTP reply back.

[fspafford]

I would like to see @ScriptLineNumber work in compiled scripts. That way, I can report errors that include the line number where they occur.

[Valik]

I would like to see @ScriptLineNumber work in compiled scripts. That way, I can report errors that include the line number where they occur.

Good luck with that.

[Richard Robertson]

Errors should be tracked down before the script is compiled.

[Valik]

AutoIt v3.3.1.7 (Beta) Released:

AutoIt:

- Fixed #1332: Mod() forced a conversion to floating point numbers when it didn't need to which can cause unexpected output.

- Fixed #1321: DllStructCreate() did not support _ in data names. Documented valid characters for data name.

- Fixed #1322: Crash when using ControlCommand("GetSelected") on non-Edit controls.

- Fixed #1328: StringFormat() was no longer accepting sequences such as 0s.

UDFs:

- Fixed #1312: Errors with _GUIImageList_BeginDrag() example.

- Fixed #1320: _GUIImageList_DragMove() documentation contained a parameter that doesn't exist.

- Fixed #1325: Some date functions could attempt to access an invalid array.

- Fixed: Invalid syntax in MenuConstants.au3.

The following changes are script breaking changes:

Some of the following features are deprecated. Deprecated features are no longer documented but continue to work. Deprecated features will be removed after version 3.3.2.0. It is strongly recommended that scripts relying on deprecated features be updated to work with the new behavior. Some features have already been removed and will be noted as such.

AutoIt:

• ShellExecute() and ShellExecuteWait() no longer use the "open" verb by default. See the remarks section for those functions for more details.
• The return value of InetGet() has changed. It is important to read and understand the changes because it is possible to leak resources if InetGet() is used incorrectly.
• InetGet("abort"),@InetGetActive and @InetGetBytesRead are now deprecated. The following list shows the new functions used to access the old behavior:
  • InetGet("abort") - Calling the new InetClose() function with a handle returned from InetGet() will abort a download.
  • @InetGetActive - Calling the new InetGetInfo() function with no parameters returns a count of active downloads.
  • @InetGetBytesRead - Calling the new InetGetInfo() function with a handle returned from InetGet()will return the bytes read (and more) for a download.
• The FtpBinaryMode option set with AutoItSetOption() has been removed. Now InetGet() takes a flag to specify the transfer mode.
• The URLDownloadToFile() alias for InetGet() has been removed.
• AdlibEnable() and AdlibDisable() are deprecated. See the new functions AdlibRegister() and AdlibUnRegister().
• OnAutoItStart() is deprecated. See the new pre-processor statement #OnAutoItStartRegister.
• OnAutoItExit() is deprecated. See the new functions OnAutoItExitRegister() and OnAutoItExitUnregister().
• The AutoItSetOption() option OnExitFunc has been removed. See the new functions OnAutoItExitRegister() and OnAutoItExitUnregister().
• GUICreate() with $WS_EX_MDICHILD has been fixed to be relative to client area as documented.
• ProcessWait() now returns a PID instead of 1 on success.
• WinWait(), WinWaitActive(), WinActivate(), WinActive() and WinMove() now return an HWND instead of 1 on succes.
• The macro@YDAY now uses the range 001 - 366 instead of 1 - 366. This makes the macro more consistent with other languages (like C/C++) and more consistent with all other date related macros which return strings with leading 0s to pad the length.
• RegEnumKey() and RegEnumVal() now return an empty string instead of an error message.

UDFs:

• The last optional parameter for _StringBetween() has been removed.
• _StringAddThousandsSep() has been removed. There are too many opinions on what this function should do and too many revisions of this function have been made.
• _SQLite_SaveMode() has been renamed to _SQLite_SafeMode().

This release is not digitally signed.

Discuss the beta here.

Report issues here.

Download here.

Edited December 10, 2009 by Valik

[Jon]

AutoIt v3.3.3.0 (Beta) Released:

AutoIt:

- Added: Ability to read and write UTF-8 files with no BOM including automatic detection during reading.

- Fixed #1345: Number() failed to handle numbers with a trailing decimal point.

- Fixed #384: Under certain circumstances the network credentials flag would prevent the process from starting when launched with RunAs() or RunAsWait().

- Fixed #1370: StringInStr() would crash with a negative occurrence and start position greater than the string length.

- Fixed #1367: Calling GUIDelete() from a GUIRegisterMsg() callback that returns $GUI_RUNDEFMSG would crash AutoIt.

- Fixed #1363: FileSetPos() did not work when the origin was the current position.

- Fixed #1355: Regression in how unsigned numbers are displayed when returned from DllCall().

- Removed: The "RAW" reading mode from FileOpen() has been removed.

UDFs:

- Changed: _SQLite 3.6.19 -> 3.6.21

- Fixed #1338: bad _ArrayDisplay() GUI position error.

- Fixed #1362: _WinAPI_WindowFromPoint() did not work with 64-bit AutoIt.

AutoIt3Help:

- Fixed #1327: Some keywords would fail to open correctly in rare cases.

Discuss the beta here.

Report issues here.

Download here.