AutoIt v3.3.13.19 Beta

[Jon]

File Name: AutoIt v3.3.13.19 Beta

File Submitter: Jon

File Submitted: 24 Aug 2014

File Category: Beta

3.3.13.19 (24th August, 2014) (Beta)
AutoIt:
- Fixed: Map setting of property using dot notation was creating duplicates.
- Fixed #2862: Regression in Copy-on-write optimization in arrays.

UDFs:
- Fixed #2853: Bad Run link in Notepad tutorial doc.
- Fixed #2854: Keyword reference doc page.
- Fixed #2861: _WinAPI_ReadDirectoryChanges() example.

Other:
- Fixed #2848: Script breaking changes not being highlighted.
- Fixed: Remarks missing in certain documentation pages.
- Fixed: Syntax highlighting missing in certain documentation pages.

Beta docs: https://www.autoitscript.com/autoit3/files/beta/autoit/docs/
Script breaking changes: https://www.autoitscript.com/autoit3/files/beta/autoit/docs/script_breaking_changes.htm

[Jon]

I've starting uploading the beta docs as well.

Beta docs: https://www.autoitscript.com/autoit3/files/beta/autoit/docs/

Script breaking changes: https://www.autoitscript.com/autoit3/files/beta/autoit/docs/script_breaking_changes.htm

[JohnOne]

Not sure if you're finished with docs, but clicked a random link https://www.autoitscript.com/autoit3/files/beta/autoit/docs/tutorials/simplecalc-josbe/simplecalc.htm and the page is weird looking, no syntax hilighting or code wrapping etc.

[guinness]

It's technically my fault, as AutoIt code in the HTML files is nowadays parsed before the chm is built. I will need to re-think this improvement of mine.

[Jon]

I missed that, I just looked at a couple of functions and they looked all pretty

[JohnOne]

I'm a little confused, are we supposed to be able to set the value of an array element in a map via dot notation now?

Because it still does not work.

[ripdad]

I think FileRead() has a problem with some files. It's producing strange characters and increases the file size when written back to a test file.

FileWrite(@ScriptDir & '\test.png', FileRead(@ScriptDir & '\image.png'))

Here are the files:

FileRead.zip

 

[BrewManNH]

You can't FileRead a binary file and expect to get anything legible out of it unless it's opened using FileOpen and the proper parameters, i.e. opened in binary mode, which you're not doing in that snippet.

[ripdad]

I didn't have any problems with 3.3.8.1 using that snippet - and also 3.3.6.1.

-edit-

No joy with FileOpen() either.

Edited August 26, 2014 by ripdad

[Jon]

Can you post a script that doesn't work with FileOpen+binary?

[jpm]

#include <FileConstants.au3>

Local $hIn = FileOpen(@ScriptDir & '\image.png', $FO_BINARY); script breaking since 3.3.12.0
Local $dBin = FileRead($hIn)
FileClose($hIn)

FileDelete(@ScriptDir & '\test.png')
FileWrite(@ScriptDir & '\test.png', $dBin)

ShellExecute(@ScriptDir & '\test.png')

Here is one which works, Just notice that it is a script breaking even in the Standard release 3.3.12.0

[BrewManNH]

Why is that script breaking?

[Jon]

It isn't really. Some people - mistakenly imo - relied on the fact that files would be opened in ANSI by default and made assumptions about how FileRead/StringLen would react to that when working with non-text files They should have been using binary mode anyway. 

The auto-detection has changed which might catch those users out. https://www.autoitscript.com/autoit3/files/beta/autoit/docs/script_breaking_changes.htm

[ripdad]

This will break over half of the scripts on the forum.

It also appears that the Default Mode has changed for FileOpen()

from 0 to something else. If I insert 0 into the mode parameter,

then it acts much better.

In any case, I have dual encodings in some of my files.

ANSI Headers with a Binary Body.

Web Browsers have no trouble with it, since that is their

Default behavior as data is streamed from a server.

It has worked great up to now.

So I'll have to figure out a solution or work-around for

this or stay with a particular version like 3.3.8.1,

which is no big deal, since it does all I want it to.

Would this be the correct usage for FileGetEncoding() ?

Local $sTest = @ScriptDir & '\test.png'
Local $sFile = @ScriptDir & '\image.png'

Local $encoding = FileGetEncoding($sFile)
MsgBox(0, '', $encoding)

Local $hFile1 = FileOpen($sFile, $encoding)
Local $hFile2 = FileOpen($sTest, $encoding + 2)
FileWrite($hFile2, FileRead($hFile1))
FileClose($hFile1)
FileClose($hFile2)

I have played with this, but can't get 100% consistent results.

FileGetEncoding() has changed quite a bit since 3.3.8.1.

It used to return all 0's -- which is ANSI.

Now, it is showing 16, 256, 1024, 2048 for the same filetype .png --

Different files with the same extension having different encodings.

Edited August 26, 2014 by ripdad

[BrewManNH]

Open the file using FileOpen and binary mode?

[ripdad]

Yep - did that. Mixed results.

[trancexx]

Jon, why is this error:

$a = 1

A($a + 5)


Func A(ByRef $x)
EndFunc

[ripdad]

I found a solution for my issue.

This seems to work across all versions.

You would have to modify it for your needs.

This is just an example (for viewing only).

Expect a crash if you run it.

;write file to drive
Local $sFile = @ScriptDir & '\image.png'
Local $hFile = FileOpen($sFile, 2 + 8 + 16); force write file in binary
FileWrite($hFile, $sRecv)
FileClose($hFile)
;
;--------------------------------------------------
;
;read file from drive
Local $sFile = @ScriptDir & '\image.png'
Local $hFile = FileOpen($sFile, 16); open file in binary
TCPSend($nSocket, BinaryToString(FileRead($hFile)))
FileClose($hFile)

Edited August 26, 2014 by ripdad

[guinness]

BrewManNH suggested that a couple of days ago.

[ripdad]

Hi guinness, you overlooked some details...