Determining real line number in script

[obrienj]

I have a 1412 line script with about 20 includes.

On rare occasions Autoit pops an error message box telling me that an "array index is out of range" or some such and terminates the script just as it should.

However, the error message references line 9216 which I guess is a line in my code after all of the includes are pre-pended.

Is there a way to either (1) save the intermediate source (after includes are resolved), (2) dis-assemble the .exe to see all lines of code, or something else so I can see exactly where the error is.

Regards,

Jim

Edited August 22, 2011 by obrienj

[Melba23]

obrienj,

When compiling your script, run Obfuscator using the /STRIPONLY parameter. That way the compiler uses an au3 file which has the include files included, but all unused functions, variables, comments and blank lines removed. It is saved in the same folder as the source and named YourScriptName_Obfuscated.au3. You need to add these directives to the top of your script:

#AutoIt3Wrapper_Run_Obfuscator=y
#Obfuscator_Parameters=/so

Then when the error occurs, it is easy to see which line gave the fault as it is this Obfuscated file which has been compiled - just scroll to the indicated location. The only problem we know of is that using the line continuation operator screws up the count, but apart from that it works fine.

Of course, you need the full SciTE4AutoIt3 package, which you can download from here if you do not already use it.

M23

[exolon]

  On 8/22/2011 at 8:53 PM, Melba23 said:

When compiling your script, run Obfuscator using the /STRIPONLY parameter. That way the compiler uses an au3 file which has the include files included, but all unused functions, variables, comments and blank lines removed. It is saved in the same folder as the source and named YourScriptName_Obfuscated.au3. You need to add these directives to the top of your script:

Great! I was just going to post about this, since I'm having exactly the same problem.

It's a shame we can't get stacktraces and source-accurate line numbers (when using the compiler). Maybe there's a way to instrument the code with debugging markers to roll your own stack trace?