How to get ANSI symbols into a compiled script?

[qwert]

I sometimes use an em dash (alt 151) character in message dialogs.  The character appears correctly when testing under SciTE.  But once I compile the script, the em dash is replaced by an odd character.  Examples are below.  I've read dozens of posts and tried several things, but I can't crack through on this one.

How can I get these extended ANSI characters into the compiled script?  The compiler seems determined to express everything in Unicode.

Thanks in advance for any help with this.

Edited April 9, 2017 by qwert

[qwert]

More searching and trying more things led me to a solution that I do not like.  I found a web site that listed the Unicode for em dash as a decimal value of 8212.

So I replaced the — character in each text string with " & ChrW(8212) & " ... and both the native script and the compiled script display the proper em dash.  But I do not know why.

To me, hard coding such values is about the same as using magic numbers in script statements.

Although I have this workaround, my question still stands: what setting will make the compiler pass the ANSI codes into the EXE?

Or to put it another way: if we can work in ANSI ... and test in ANSI ... how do we make the compiler honor that ANSI?

 

[Jos]

Have you tried changing the file encoding of the scriptfile from the defaut utf-8 without bom to Code Page property?

Jos

 

Edited April 9, 2017 by Jos

[qwert]

Here's what I have.  Per your suggestion, is this correct?  (... and considered a "best practice"? ... because I don't recall ever changing it.)

[Jos]

Well, the last couple of SciTE versions will use UTF-8  as the default option to support unicode, but it will only default to it when an file doesn't contain any "special" ascii characters.  Seems you either use an older version of SciTE or the file actually does contain one or more special ascii characters.
How are you compiling ? 
Are you using any utilities like Tidy and/or au3stripper that could change the file content since to stated that running the script it works fine but not when compiled?

If so, which versions? (Show me the whole SciTE outputpane info when you compile the script).

Jos

[qwert]

Screen capture is below.  As you can see, I do use the strip option.  Here's the full text of the compile command line:

Quote

>Running:(3.3.14.2):C:\AutoIt3\aut2exe\aut2exe.exe  /in "D:\Au3 MASTERS\Click Pad\ClickPad+_stripped.au3" /out "C:\Users\TwigSoft64\AppData\Local\AutoIt v3\Aut2exe\~AU3nsishzx.exe" /nopack /icon "D:\Au3 MASTERS\Icons\ClickPad.ico" /comp 2

 

 

[Jos]

What happens when you run the "Click Pad\ClickPad+_stripped.au3" files version of the script from within SciTE?
Is the special ansii character located in the master/main script or one of its included files?
What encoding does the  "Click Pad\ClickPad+_stripped.au3"  source file have? 

You are running pretty outdated versions of the utilities so maybe you could try the latest version of Autoit3Wrapper and au3stripper.

Jos

[qwert]

Quote

What happens when you run the "Click Pad\ClickPad+_stripped.au3" files version of the script from within SciTE?

It fails, the same as the EXE.

Quote

Is the special ansii character located in the master/main script or one of its included files?

It's in the main script.

Quote

What encoding does the  "Click Pad\ClickPad+_stripped.au3"  source file have? 

How do I determine that?  "Properties" doesn't seem to have an indication of encoding.

BTW, I'll look at upgrading.  I really didn't think I was that far behind, with my v3.3.14.2 load.  I try to stick with major releases.

[Jos]

 

17 minutes ago, qwert said:

It fails, the same as the EXE.

 This would indicate that the file encoding is changed in the stripper process. Just try using the current au3stripper in your setup to see if that fixes it.

17 minutes ago, qwert said:

How do I determine that? 

Same as the previous time, open in SciTE and look what File/Encoding shows.

Jos

Edited April 10, 2017 by Jos

[qwert]

Quote

Same as the previous time, open in SciTE and look what File/Encoding shows.

Sorry, I didn't think.  It shows Code Page Property.  I'll locate the current stripper.

[Jos]

7 minutes ago, qwert said:

It shows Code Page Property

Ok, so that is the same as the original source code containing the statement with the dash character. Did you check the code in the stripped version?

Just try this version: https://www.autoitscript.com/autoit3/scite/download/beta_SciTE4AutoIt3/Au3Stripper.exe

Jos

[qwert]

Quote

Did you check the code in the stripped version?

If you mean are the em dash characters in the stripped version, the answer is yes.

But I've found a big anomaly on my PC.  The SciTE I'm actually using is 3.5.4 ... from 2015.  I have a later version in a parallel directory that's not being accessed.  I recall some problem in setting up my new PC early this year that caused me to waive off of the latest and just run with what worked.

You've pointed me in the right direction, but it may take me a day or two to sort this out.  I'll post when I have valid results to report.

I greatly appreciate your help on this. 

[Jos]

Your welcome and let me know in case you need more assistance with debugging. Maybe upgrade to the latest version of the SciTE4AutoIt3 installer anyway as I have made many changes since the version you are running... also in the support of ANSI and UTF8 files.

Jos

[qwert]

Good news.  Bad news.

I'm pleased to report that the newest Au3Stripper does properly handle extended characters ... like emdash and the copyright symbol.

But I'm dismayed by the fact that it apparently removed a variable that is referenced by the following statement:

Global Const $tagREBARBANDINFO = "uint cbSize;uint fMask;uint fStyle;dword clrFore;dword clrBack;ptr lpText;uint cch;" & "int iImage;hwnd hwndChild;uint cxMinChild;uint cyMinChild;uint cx;handle hbmBack;uint wID;uint cyChild;uint cyMaxChild;" & "uint cyIntegral;uint cxIdeal;lparam lParam;uint cxHeader" &((@OSVersion = "WIN_XP") ? "" : ";" & $tagRECT & ";uint uChevronState")

I'll grant that this use of $tagRECT is not simple.  But this statement works fine in the older version of Au3Stripper.  And by the looks of it, the statement is from a UDF.  Maybe I can isolate the section of code and bring it into my script. 

I'll report my progress and will appreciate any advice on how to work around this problem. 

[Jos]

Send/PM me a (small) example script that shows the behaviour and I will do some debugging.

Jos

[mLipok]

Do you have any progress ?

[qwert]

Limited progress.  I ran into some #pragma versus wrapper issues that complicated my investigation. I hope to get everything sorted out this week. I'll post what I determine.

I will mention that I added this directive, which seemed to restore the $tagRECT reference:

#Au3Stripper_Ignore_Variables=$tag*

 

Edited May 24, 2017 by qwert