Macro for file name in included files

[anonymous]

The sitation: 22 source files, even more unit tests and hundreds of functions that call a helper function containing an assertion.

The problem: The assertion fails (preventing a crash) and I don't know where and why. I don't know which function called the helper function and I'll have to add debug statements to a couple of functions.

These are my values. They can vary from person to person. But the problem is the same.

Please make it possible to access the file name of the caller of a function, just like @ScriptLineNumber. When a script crashes, both are printed; the information is present, but not accessible. Please change that.

[Melba23]

In a compiled script there are no "source files" as such to identify. Using #include is the same as pasting the content of that file into the script at that point, so all code is essentially inside the same script once compiled.

Note the Help file comments for @ScriptLineNumber;;

Line number being executed - useful for debug statements
(e.g. location of function call).
Only significant in uncompiled scripts - 
note that #include files return their internal line numbering

When running from SciTE, the editor can distinguish from which file a particular line of code is derived - as explained above, when compiled there are no separate files, so I am afraid that your request makes no sense.

What you can do to identify a line on which AutoIt crashes is to use Au3Stripper which reduces your script to the same number of lines as read by the compiler - then the line number shown in the error MsgBox reflects the line in the stripped file. But I do not believe that this will help in your particular situation - other than if you allow the crash while debugging rather than using the assertion in the helper function.

M23

[anonymous]

Replying to Melba23:

In a compiled script there are no "source files" as such to identify. Using #include is the same as pasting the content of that file into the script at that point, so all code is essentially inside the same script once compiled.

I do not compile it for testing.

Note the Help file comments for @ScriptLineNumber;;

Line number being executed - useful for debug statements
(e.g. location of function call).

That's what I'm using it for.

Only significant in uncompiled scripts - 
note that #include files return their internal line numbering

I don't compile it, no problem.

When running from SciTE, the editor can distinguish from which file a particular line of code is derived

Unfortunately I only know the line number of the line and not it's content.

[...] allow the crash while debugging rather than using the assertion in the helper function.

If I do that, then I know that it crashed in the line after the assertion. If I use the assertion, then I know the line number of the line where the function was called (using @ScriptLineNumber as default argument in the helper function). If I also knew the file, then I knew where to look for the bug.

[Melba23]

If you use Au3Stripper as I suggested then you will only have the one file with the includes inserted and so the line number will be easy to locate.

M23

[anonymous]

Replying to Melba23:

If you use Au3Stripper as I suggested then you will only have the one file with the includes inserted and so the line number will be easy to locate.

Thank you, you are right.

Back on topic:
I don't think that the suggested macro should be denied existence when @ScriptLineNumber exists (justification and use case above). Please create that macro.

[Jos]

Replying to anonymous:

Back on topic:
I don't think that the suggested macro should be denied existence when @ScriptLineNumber exists (justification and use case above). Please create that macro.

The is logic in your request as the @ScriptLineNumber is the actual one from the include file.
Maybe @SriptName and @ScriptFullPath should also be set to the actual include file being processed at the time.

Jos

[anonymous]

Replying to Jos:

Maybe @ScriptName and @ScriptFullPath should also be set to the actual include file being processed at the time.

Maybe @ScriptCurrentFileName, @ScriptCurrentFullPath and @ScriptCurrentDir (or @CurrentScript...). Re-using existing macros might break existing scripts.

[mLipok]

Duplicated ?

​https://www.autoitscript.com/trac/autoit/ticket/3766
​​https://www.autoitscript.com/trac/autoit/ticket/2963

[mLipok]

try to use SciTE4Au3 + Au3Stripper with /rsln

*** Updated Au3Stripper v18.708.1148.0 (Jos) - 17.224.935.2 Changed /rsln to replace @ScriptLineNumber in the Master script with "XXX/YYY". XXX is the master script linenumber, YYY is the Merged script linenumber.

to the anonymous OpeningPoster:

If you back to us, does not hold back and answer here.

But for now this ticket will be closed.

[mLipok]

for all interested "related" feature is here:
​https://www.autoitscript.com/trac/autoit/ticket/2886

[vanowm <autoitscript@…>]

Please re-open this ticket. Currently there are two ways get the main scriptname: via $CmdLine and @ScriptName, however there no way get the included scriptname at all.
It just doesn't make sense that @ScriptLineNumber points to one file, but @ScriptName points to another.

[anonymous]

We also have encountered a great need for this macro
(lets call it @ThisScript(which contains the full path to the script from which it is invoked, EVEN WHEN this script is #include'd inside another -- that's the whole point!), or @ScriptLineNumberWithFile - which contain the linenumber AND the file from which it is invoked, like eg "line 15 in D:\test\includes\myinclude2.au3")

Now, take a deep breath and in a step-by-step manner please reconsider and add this macro!

Absence of a way to get the name of included file has costed us, and evidently other users, countless hours of frustrating and nerve-wrecking bug-hunting!

One day, i was doing just that, trying to find this pesky bug that was happening in some included UDF, and was getting so annoyed, that i shouted at my cats to stop pestering me to feed them! They were left hungry for 4 hours... So, if making the users life better isn't a sufficient reason to sway your harsh judgement the other way, then at least think of the kittens and do it for their rumbling (and very fluffy) tum-tums' sake!

When it's done, I promise to buy them the best and very expensive treats, and we will celebrate together.