Wish to Add "Stop on end" option

[PythonYunfei]

There are two advantages to achieving this: First, with this feature, we can directly look through variables in the editor every time we debug, without manually adding any breakpoint. With this inline setting below, we can see their values and properties very conveniently whenever we want: Second, with this feature, via customed debug shortcut keys, debug console can not only be opened while debugging launched but also can be closed automatically right after we finish seeing the results in console and variables in editor. This demand can be achieved when this feature is combined with the following settings: Because the debug console can be closed automatically by settings, we need "Stop on end" to temporarily prevent it. It will be quite perfect to achieve this feature.

[zero-plusplus]

I am not sure what "stop on end" represents.

Does it mean break just before the end of the script?

[PythonYunfei]

@zero-plusplus
Mostly right, but to be exact, I prefer stopping before the debug ends or preventing the debug mode from quitting to keep me watching the results and variables. like this: As the above picture shows, it's not that convenient as I need to set a breakpoint or do something else to prevent it from ending. Also, the breakpoint will not work in VSCode as long as it is accidentally set a little farther to my code like this: More importantly, the debug console will close immediately so I don't have time look at the output results as I have set the VSCode in advance to automatically keep the debug console closed when I write codes. Now the rest is to keep the debug console open when I want to watch it. I hope the debug console will close only when I want it closed and stop debugging, with a single shortcut key press. As you've asked about in another issue I pulled, I have not used launch.json. All my settings including the launch settings, are all in a workspace file:

"settings": {
        "[ahk2]": {
            "editor.quickSuggestions": {
                "other": true,
                "comments": false,
                "strings": true,
            },
            "files.encoding": "utf8"
        },
        "files.associations": {
            "*.ah2": "ahk2",
            "*.ahk2": "ahk2",
            "*.ahk": "ahk2",
            "*.ahk1": "ahk"
        },
        "extensions.experimental.useUtilityProcess": true,
        "AutoHotkey2.ActionWhenV1IsDetected": "SwitchToV1",
        "AutoHotkey2.CompilerCMD": "/gui /compress 0 /base ${execPath}",
        // "AutoHotkey2.InterpreterPath": "${AHK2Interpreter:AHK2Interpreter}\\AutoHotkey64.exe",
        "AutoHotkey2.InterpreterPath": "E:\\AHK\\AHK2Interpreter\\AutoHotkey64.exe",
        "AutoHotkey2.CompleteFunctionParens": true,

        "debug.autoExpandLazyVariables": true,
        "debug.console.fontSize": 14,
        "debug.console.wordWrap": true,
        "debug.inlineValues": "on",
        "debug.internalConsoleOptions": "neverOpen",
        "debug.console.closeOnEnd": true,
        "debug.openExplorerOnEnd": true,
        "debug.showBreakpointsInOverviewRuler": true,

        "editor.bracketPairColorization.independentColorPoolPerBracketType": true,
        "editor.hover.delay": 0,
        "editor.hover.sticky": false,
        "editor.scrollbar.scrollByPage": true,
        "editor.scrollbar.verticalScrollbarSize": 15,
        "editor.semanticHighlighting.enabled": true,
        "editor.smoothScrolling": true,
        "editor.fontSize": 13,
    },
    "launch": {
        // Use IntelliSense to learn about possible attributes.
        // Hover to view descriptions of existing attributes.
        // For more information, visit: https://go.microsoft.com/fwlink/?linkid=830387
        "version": "0.2.0",
        "configurations": [
            {
                "type": "autohotkey",
                "request": "launch",
                "name": "AhkDebuggerPlus",
                "program": "${file}",
                "stopOnEntry": false,
                // "runtime_v2":"${workspaceFolder:AHK2Interpreter}\\AutoHotkey64.exe",
                "runtime_v2":"${fileWorkspaceFolder}\\Interpreter\\AutoHotkey64.exe",
                "runtime_v1":"C:\\Program Files\\AutoHotkey\\AutoHotkeyU64.exe",
                // "useDebugDirective":true,
                // "useAutoJumpToError":true,
            },
            {
                "extends": "AhkDebuggerPlus",
                "type": "autohotkey",
                "request": "launch",
                "name": "AH2Debugger",
                // "program": "${file}",
                // "stopOnEntry": false,
                "runtime_v2":"${workspaceFolder:AH2Interpreter}\\AutoHotkey64.exe",
                // "runtime_v1":"C:\\Program Files\\AutoHotkey\\AutoHotkeyU64.exe",
                // // "useDebugDirective":true,
                // // "useAutoJumpToError":true,
            },
        ],
    }

[zero-plusplus]

The debugger only notifies the client that debugging is finished and cannot break just before the end.

It also cannot retrieve information such as variables from an finished script.

The following two are alternatives.

1. If the script is not in Persistent mode, you can place a breakpoint on the last line of the main script, as in your image, to break just before the end
2. If you want to break more strictly just before the end, you can specify a function with OnExit and place a breakpoint at the end of that function.

If setting these breakpoints from the UI is not convenient, use breakpoint directive.

---

Regarding the second image, this does not seem to be an inherent bug of this extension, as SciTE4AutoHotkey had the same problem.

This problem can be worked around by putting a return statement in the last line.

[PythonYunfei]

Thanks very much for your answers. You can either ignore it below. I would like to ask, for a last try.

The debugger only notifies the client that debugging is finished and cannot break just before the end.

Can it break before the debugger notify? I just prefer to have a try to let it better one step further.😜

Does it mean break just before the end of the script?

It would also be better if you can achieve automatically setting breakpoint to the code end like that above. Because my breakpoint I set is often too far to be available.

[zero-plusplus]

The only way to completely solve this issue is for the AutoHotkey debugger to handle it.

However, you can get as near as possible to your request by loading the following script using the command line argument /include. This requires setting useDebugDirective to true in launch.json.ahk

As I was writing, I noticed that the current spec does not recognize debug directives for files loaded with /include. Therefore, this alternative will be effective in the next version.

OnExit(Func("__OnExit__"))
__OnExit__() {
  ; @Debug-Breakpoint
}

---

It would also be better if you can achieve automatically setting breakpoint to the code end like that above. Because my breakpoint I set is often too far to be available.

You can use setHiddenBreakpoints, which is being implemented now, to place breakpoints at the end of files, at the end of certain functions, etc. This will be available in the next major update.

[zero-plusplus]

I have opened an issue to fix the bugs necessary to implement the above workaround.

This issue will be closed when the above bug is fixed and a major update is released.

If the AutoHotkey debugger supports it, please reopen it or open a new issue.

[PythonYunfei]

Thank for your great work. /include is the most perfect idea which I never come up with, if it can be combined with your debugger. Also, I prefer /include can be directly integrated in one setting file instead of using debug directives in every file, like setHiddenBreakpoints. I am sure the plugin will go one big step further with stop on end setting, not losing to the stop on entry setting at all.

[PythonYunfei]

In addition, be better if can add a judgment: if any breakpoints are set by users self, /include will not work, to avoid unnecessary file including.

[zero-plusplus]

Let me ask you, how would you use this feature?

You mention being able to check variables as an advantage, but do you want to test some function?

I feel there is a better solution than implementing this feature at the moment.

---

In addition, be better if can add a judgment: if any breakpoints are set by users self, /include will not work, to avoid unnecessary file including.

Currently the benefit to this feature is not clear. There is also too much complexity regarding the above feature.

Let's explore this issue a bit further.

[zero-plusplus]

One announcement, the Exception breakpoint included in the next major update has the property of breaking when an exception occurs, so it will break at the end of the script in a pseudo manner.

If you are trying to use the feature of this issue as some kind of test, you may be able to solve this problem by using a exception breakpoint.

[PythonYunfei]

Let me ask you, how would you use this feature?

You mention being able to check variables as an advantage, but do you want to test some function?

I mainly used this feature for testing or learning some simple v2 codes like that below, preventing the console from closing and seeing all of the global variable with debugger at the same time. if you import my settings posted yesterday then you may feel the demand which is needed with the settings😜. The main benefit is that I don't need to set a breakpoint at the end by using mouse for a V2 language feature testing and learning. As soon as any break points are set, the feature becomes unnecessary and should avoid unnecessary /include.

I feel there is a better solution than implementing this feature at the moment.

Expect to have a listen.

[PythonYunfei]

One announcement, the Exception breakpoint included in the next major update has the property of breaking when an exception occurs, so it will break at the end of the script in a pseudo manner.

If you are trying to use the feature of this issue as some kind of test, you may be able to solve this problem by using a exception breakpoint.

Sounds great. I have not know about it yet. Do I need to write some code to throw an uncatched exception on the end of script to invoke the exception breakpoint?

[zero-plusplus]

Breaks on caught or uncaught or both patterns.

For example, if a variable has an abnormal value, you can write a throw statement with an if statement to break only when a problem occurs.

[zero-plusplus]

I mainly used this feature for testing or learning some simple v2 codes like that below, preventing the console from closing and seeing all of the global variable with debugger at the same time. if you import my settings posted yesterday then you may feel the demand which is needed with the settings😜. The main benefit is that I don't need to set a breakpoint at the end by using mouse for a V2 language feature testing and learning.

I understand.

You are trying multiple test codes with global scope?

If this is the case, could you solve this by placing a breakpoint directive on the last line?

[PythonYunfei]

Breaks on caught or uncaught or both patterns.

For example, if a variable has an abnormal value, you can write a throw statement with an if statement to break only when a problem occurs.

Do I need to write a code like this to achieve the same effect with /include feature?

; v2.0.0
OnExit(__OnExit__)
__OnExit__(c,d){
  throw({what:'endError'})
}

You are trying multiple test codes with global scope?

Yes, quite right.

could you solve this by placing a breakpoint directive on the last line?

It's not the same. With a breakpoint directive, I need to write code every time in every file. However, with /include feature, I only have to write code only once in only one setting file.

[zero-plusplus]

Do you have multiple test codes and debug each one?

You can use the ${file} variable to setHiddenBreakpoints to set breakpoints on the last line of the file being debugged.

Once again, setHiddenBreakpoints is a feature that will be included in the next major update.

"setHiddenBreakpoints": [
  {
    "target": "${file}",
    "line": -1,
  }
]

[PythonYunfei]

Do you have multiple test codes and debug each one?

I mainly use only one debugger for files of multiple workspace folders in a workspace, apart from another 'V2H' debugger.

    "launch": {
        // Use IntelliSense to learn about possible attributes.
        // Hover to view descriptions of existing attributes.
        // For more information, visit: https://go.microsoft.com/fwlink/?linkid=830387
        "version": "0.2.0",
        "configurations": [
            {
                "type": "autohotkey",
                "request": "launch",
                "name": "AhkDebuggerPlus",
                "program": "${file}",
                "stopOnEntry": false,
                // "runtime_v2":"${workspaceFolder:AHK2Interpreter}\\AutoHotkey64.exe",
                "runtime_v2":"${fileWorkspaceFolder}\\Interpreter\\AutoHotkey64.exe",
                "runtime_v1":"C:\\Program Files\\AutoHotkey\\AutoHotkeyU64.exe",
                "usePerfTips": {
                    "format": "{{elapsedTime_s}}s passed",
                    "fontStyle": "italic",
                    "fontColor": "yellow"
                }
                // "useDebugDirective":true,
                // "useAutoJumpToError":true,
            },
            {
                "extends": "AhkDebuggerPlus",
                "type": "autohotkey",
                "request": "launch",
                "name": "AH2Debugger",
                // "program": "${file}",
                // "stopOnEntry": false,
                "runtime_v2":"${workspaceFolder:AH2Interpreter}\\AutoHotkey64.exe",
                // "runtime_v1":"C:\\Program Files\\AutoHotkey\\AutoHotkeyU64.exe",
                // // "useDebugDirective":true,
                // // "useAutoJumpToError":true,
            },
        ],
    }
}

Once again, setHiddenBreakpoints is a feature that will be included in the next major update.

Congratulations!

You mention being able to check variables as an advantage, but do you want to test some function? I feel there is a better solution than implementing this feature at the moment. One announcement, the Exception breakpoint included in the next major update has the property of breaking when an exception occurs, so it will break at the end of the script in a pseudo manner. If you are trying to use the feature of this issue as some kind of test, you may be able to solve this problem by using a exception breakpoint

Also waiting for this feature, exception breakpoint.

[PythonYunfei]

Do you have multiple test codes and debug each one?

I use only one debugger for files of multiple workspace folders mainly in a workspace apart from another 'V2H' debugger.

    "launch": {
        // Use IntelliSense to learn about possible attributes.
        // Hover to view descriptions of existing attributes.
        // For more information, visit: https://go.microsoft.com/fwlink/?linkid=830387
        "version": "0.2.0",
        "configurations": [
            {
                "type": "autohotkey",
                "request": "launch",
                "name": "AhkDebuggerPlus",
                "program": "${file}",
                "stopOnEntry": false,
                // "runtime_v2":"${workspaceFolder:AHK2Interpreter}\\AutoHotkey64.exe",
                "runtime_v2":"${fileWorkspaceFolder}\\Interpreter\\AutoHotkey64.exe",
                "runtime_v1":"C:\\Program Files\\AutoHotkey\\AutoHotkeyU64.exe",
                "usePerfTips": {
                    "format": "{{elapsedTime_s}}s passed",
                    "fontStyle": "italic",
                    "fontColor": "yellow"
                }
                // "useDebugDirective":true,
                // "useAutoJumpToError":true,
            },
            {
                "extends": "AhkDebuggerPlus",
                "type": "autohotkey",
                "request": "launch",
                "name": "AH2Debugger",
                // "program": "${file}",
                // "stopOnEntry": false,
                "runtime_v2":"${workspaceFolder:AH2Interpreter}\\AutoHotkey64.exe",
                // "runtime_v1":"C:\\Program Files\\AutoHotkey\\AutoHotkeyU64.exe",
                // // "useDebugDirective":true,
                // // "useAutoJumpToError":true,
            },
        ],
    }
}

Once again, setHiddenBreakpoints is a feature that will be included in the next major update.

Congratulations!

You mention being able to check variables as an advantage, but do you want to test some function? I feel there is a better solution than implementing this feature at the moment. One announcement, the Exception breakpoint included in the next major update has the property of breaking when an exception occurs, so it will break at the end of the script in a pseudo manner. If you are trying to use the feature of this issue as some kind of test, you may be able to solve this problem by using a exception breakpoint

Also waiting for this feature, exception breakpoint..

[zero-plusplus]

I use only one debugger for files of multiple workspace folders mainly in a workspace apart from another 'V2H' debugger.

Then I guess it can be solved by using the ${file} mentioned above.

I have no plans to implement the stopOnEnd attribute in my current thinking.

The reason is that when a script ends, the interest is not in the change of the variable state, but whether it ended abnormally or not. If the script exits normally, there is no need to break the script, and if it exits abnormally, an Exception breakpoint will give the details.

If you are satisfied with the reasons for this, I will close this issue.

[PythonYunfei]

Yes, no problem. It is really not a big demand and setHiddenBreakpoints can solve it in the next version.

[zero-plusplus]

ok. I close this issue.

If you have any requests for the setHiddenBreakpoints feature, you can do so here.

[PythonYunfei]

ok. I close this issue.

If you have any requests for the setHiddenBreakpoints feature, you can do so here.

Thanks.