Modify

Opened 5 years ago

Last modified 5 years ago

#2963 new Feature Request

Macro for file name in included files

Reported by: anonymous Owned by:
Milestone: Component: AutoIt
Version: Severity: None
Keywords: Cc:

Description

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.

Attachments (0)

Change History (6)

comment:1 follow-up: Changed 5 years ago by 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

comment:2 in reply to: ↑ 1 Changed 5 years ago by 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.

comment:3 follow-up: Changed 5 years ago by 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

comment:4 in reply to: ↑ 3 ; follow-up: Changed 5 years ago by 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.

comment:5 in reply to: ↑ 4 ; follow-up: Changed 5 years ago by 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 @ScriptName and @ScriptFullPath should also be set to the actual include file being processed at the time.

Jos

Last edited 5 years ago by Jos (previous) (diff)

comment:6 in reply to: ↑ 5 Changed 5 years ago by 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.

Guidelines for posting comments:

  • You cannot re-open a ticket but you may still leave a comment if you have additional information to add.
  • In-depth discussions should take place on the forum.

For more information see the full version of the ticket guidelines here.

Add Comment

Modify Ticket

Action
as new The ticket will remain with no owner.
Author


E-mail address and user name can be saved in the Preferences.

 
Note: See TracTickets for help on using tickets.