January 2, 2019: New SciTE4AutoIt3 available with the updated SciTE v4.1.2 release

[ldub]

When I switch back, all is correct except the a with accent grave ( all of them  remain unreadable )

See the result, picture 3 and 4 (previous page).

Edited April 8, 2019 by ldub

[jchd]

0xC3 is the first byte of a number of UTF8 sequences. By itself it's invalid unless followed by a suitable sequence, forming a valid UTF8 codepoint representation. For instance 'à' (U+00E0) encodes as 0xC3 0xA0 in UTF8.

Invalid lone 0xC3 in the middle of a UTF8 string (the source in pic 4) probably confuses the UTF8 detection.

Overwrite all the bad-looking à in the UTF8 source and all should work fine.

Edited April 8, 2019 by jchd

[ldub]

Indeed, if I replace the 0xC3, everything goes in the order.
However, that does not solve my problem: when I use Tidy, the utf8 mode is removed and I have to select it manually via the menu.

[jchd]

Then there are one or more other invalid UTF8 sequences somewhere.

[ldub]

My configuration of SciTEGlobal.properties and SciTEUser.properties "internationalization" is the same as for my Scite version 4.1 which works fine.
 

.

 

[ldub]

Jchd and Jos,

I took the big steps, I uninstalled and then reinstalled Autoit and Scite.
It was the good decision. Everything works well now.

Thank you so much for your help, sorry for taking your time.

Ldub

 

[argumentum]

@Jos, I'm working from an Admin account but then decided to work from a non-admin account and getting the error:

- ### C:\AutoIt3\SciTE\Au3Stripper\Au3Stripper.dat missing... Please get it from the website to make sure the Au3Stripper will work correctly.

so I copied "C:\Users\Test\AppData\Local\AutoIt v3\SciTE\Au3Stripper\au3Stripper.dat" to the Au3Stripper folder, and that solved it.
This other user account, is not the one, that AutoIt and SciTE was installed under.

As this may be cryptic: user "Test" is the Administrator, then I made a user called "Other" with user group only.
The mishap is when running from user Other.

I'm writing this, thinking that it may be better to install the DAT file in the same folder as the EXE in future versions of the SciTE installer.

This is a non-issue, just an idea.

[Deye]

On 4/8/2019 at 3:58 PM, jchd said:

Invalid lone 0xC3 in the middle of a UTF8 string (the source in pic 4) probably confuses the UTF8 detection.

What happens otherwise if SciTE detects UTF8 for a file but opens it as read:  UTF8 with BOM
Will that solve all cases of any UTF8 reading problems ?
Is it workable to save a file opened as  UTF8 + BOM to just UTF8

Just a thought ..

 

[Jos]

13 hours ago, argumentum said:

I'm writing this, thinking that it may be better to install the DAT file in the same folder as the EXE in future versions of the SciTE installer.

This is a non-issue, just an idea.

We had to change that when Win7+ was introduced and the Program files directory wasn't writetable by default anymore for the regular user due to the security changes.
So I moved the config files to the user's directory to make that work again without issues. Obviously this means now that the userfiles needs to be either copied or a new install needs to be made for each user.  The portable installation still looks for the configfiles in the program directory as that is the only way to make it portable, but then it is assumed the user does have full rights to that subdirectory. The location of the files is determined by the presence of the environment variable SCITE_USERHOME.

Jos 

[Jos]

1 hour ago, Deye said:

What happens otherwise if SciTE detects UTF8 for a file but opens it as read:  UTF8 with BOM

Not sure I understand that statement/question: SciTE will only try to figure out the encoding when there is no BOM at the beginning of the file. 

Jos

[Deye]

Hi Jos,

@how does SciTE  open UTF8 files ?
I'm guessing that if they are without BOM then they are opened as Read\Write without BOM ,And saved as such
But what if they can be opened with BOM as read, Nothing to do with the saving part ..

@what will be the impact then ..

Deye

 

 

 

[Jos]

Sorry, but don't understand what you mean. The BOM is the first couple of characters (different per type of encoding)  where SciTE tests for when opening.
When there is a BOM there is nothing to do other than reading the characters in a different way so they presented in the correct form and a Save time it does the reverse....pretty straightforward.

The can of worms start with UTF8 without BOM as that file contains some double byte characters and some single byte characters.  The issue is tpo properly determine whether a double byte character starts or a High Ascii Character (128-255) as when the latter happens you need to use the ANSI encoding.

Jos

[NSUSpray]

AutoIt3Wrapper 19.102.1901.0 creates executable file much larger than AutoIt3Wrapper 16.612.1119.0.

For example:

AutoIt 3.3.14.5 + AutoIt3Wrapper 16.612.1119.0 (x86) - 385 KB
AutoIt 3.3.14.5 + AutoIt3Wrapper 16.612.1119.0 (x64) - 420 KB

AutoIt 3.3.14.5 + AutoIt3Wrapper 19.102.1901.0 (x86) - 720 KB
AutoIt 3.3.14.5 + AutoIt3Wrapper 19.102.1901.0 (x64) - 755 KB

Why did it happen?

Command line parameters: /comp 4 /pack. UPX version: 3.91w.

Edited April 27, 2019 by NSUSpray

[argumentum]

1 hour ago, NSUSpray said:

Why did it happen?

MsgBox(262144, @ScriptName, '@AutoItVersion:  ' & @AutoItVersion, 30)

Compiled with v3.2.0.1  is 374 KB, 179 KB with upx
Compiled with v3.2.12.1 is 515 KB, 255 KB with upx
Compiled with v3.3.8.1  is 635 KB, 295 KB with upx
Compiled with v3.3.14.5 is 846 KB, 375 KB with upx

So, as AutoIt can do more, more code is in the executable.
Is not the wrapper.
 

Edited April 27, 2019 by argumentum
added upx'd sizes

[NSUSpray]

33 minutes ago, argumentum said:

MsgBox(262144, @ScriptName, '@AutoItVersion:  ' & @AutoItVersion, 30)

Compiled with v3.2.0.1  is 374 KB, 179 KB with upx
Compiled with v3.2.12.1 is 515 KB, 255 KB with upx
Compiled with v3.3.8.1  is 635 KB, 295 KB with upx
Compiled with v3.3.14.5 is 846 KB, 375 KB with upx

So, as AutoIt can do more, more code is in the executable.
Is not the wrapper.
 

AutoIt 3.3.14.5 in all cases.

If I use another version of Aut2exe, the situation repeats. For example:

AutoIt 3.3.14.2 + AutoIt3Wrapper 16.612.1119.0 (x86/x64) - 383 KB
AutoIt 3.3.14.2 + AutoIt3Wrapper 19.102.1901.0 (x86/x64) - 718 KB

[argumentum]

..seems to me as one is using UPX compressor just by the sizes alone.
Another reason may be the version of UPX ?
Do check for that. Let me know if that is not it.

[NSUSpray]

9 minutes ago, argumentum said:

..seems to me as one is using UPX compressor just by the sizes alone.
Another reason may be the version of UPX ?
Do check for that. Let me know if that is not it. 

UPX 3.91w and command line parameters "/comp 4 /pack" in all cases.

Without "/comp 4 /pack":

AutoIt 3.3.14.5 + AutoIt3Wrapper 16.612.1119.0 (x86) - 857 KB
AutoIt 3.3.14.5 + AutoIt3Wrapper 19.102.1901.0 (x86) - 1160 KB

Edited April 27, 2019 by NSUSpray

[argumentum]

I have no idea of what can be producing such dramatic size difference. The wrapper, wraps the Aut2exe command line ( and the Tidy, Stripper, etc. for convenience ), but basically, that is all it does. I've used them all and never had such results as you have.
I answered to the post thinking that you may be a new to AutoIt and not know why it may be happening, but that is the extent I can contribute.
Maybe the one who wrote the wrapper can help you better than I did. Sowy 😕

[Jos]

Give me  one example script  with the used directives, with the your exact results for the 16.* and the 19.* version,  and I will have a look to see whether I can replicate the issue you see.

Jos

[NSUSpray]

4 hours ago, Jos said:

Give me  one example script  with the used directives, with the your exact results for the 16.* and the 19.* version,  and I will have a look to see whether I can replicate the issue you see.

Jos

I found a possible cause.

; Make.au3
$wrapperPath = @ComSpec & ' /c "' & @ProgramFilesDir & '\AutoIt3\SciTE\AutoIt3Wrapper\AutoIt3Wrapper.au3"'
RunWait ($wrapperPath & ' /in example.au3 /out example.exe')
RunWait ($wrapperPath & ' /in example_callback.au3 /out example_callback.exe')

; example.au3
#AutoIt3Wrapper_Run_Au3Stripper=Y
#include <GDIPlus.au3>
#include <Array.au3>
foo()
func foo()
    MsgBox (0, "", "")
endfunc

; example_callback.au3
#AutoIt3Wrapper_Run_Au3Stripper=Y
#include <GDIPlus.au3>
#include <Array.au3>
foo()
func foo()
    MsgBox (0, "", "")
endfunc
HotKeySet("a", FuncName(foo))       ; or Call($funcName) (variable instead string) etc.

example.exe - 847 KB

example_callback.exe - 980 KB

Such a marked effect appeared in the 19 version of wrapper, in 17 it was not.

Edited April 27, 2019 by NSUSpray