Support attach

[zero-plusplus]

In order to attach, the following AutoHotkey script needs to be run.

Source:

ScriptPath := "" ; SET THIS TO THE FULL PATH OF THE SCRIPT
DetectHiddenWindows On
if WinExist(ScriptPath " ahk_class AutoHotkey")
    ; Optional parameters:
    ;   wParam  = the IPv4 address of the debugger client, as a 32-bit integer.
    ;   lParam  = the port which the debugger client is listening on.
    PostMessage DllCall("RegisterWindowMessage", "str", "AHK_ATTACH_DEBUGGER")

I never got around to implementing this until now because I assumed I needed to have an alternative program in TypeScript. In fact, it seems that it can attach it by running this script before start debugging.

I wrote test code and it was actually possible to attach. However, there were some problems such as not being able to execute some commands, so it doesn't seem to be something that can be implemented immediately.

Problems in implementation

• In the case of attach, the only way to get a stream such as stdout is through the AutoHotkey debugger. However, it can only retrieve some messages using FileAppend or OutputDebug, and not error messages. The solution to this is to get the stream from the pid in Node.js, but I can't find a way to do that at the moment

[SAbboushi]

I like that you are trying to do this. For now, I use Lexikos' debugvars.ahk so I can at least see values of scripts that are not running under debugger control.

[zero-plusplus]

I thought debugvars.ahk was a script to display variables during debugging. Thanks for the useful information.

I've been debugging my regular scripts more often lately and I've realized the need for attach. Without it, the script would have to be restarted every time.

I'll be implementing it as soon as possible.

[SAbboushi]

I am glad!

[zero-plusplus]

The stdout problem I mentioned above can't be solved in the usual way, apparently.

My problem was that the script would exit after debugging. While doing my research I noticed that I found a way to keep the script running after the debugging had finished.

This means I can add a setting like detachProgramOnExit to accomplish my goal.

So let me ask you, what is the reason you are asking for attach? If the above setting solves the problem, I'm thinking of putting off the costly attach.

[zero-plusplus]

This issue shares a lot of processing with #78, so we will implement it at the same time.

[zero-plusplus]

I am ready to implement this feature. It will be enabled in the next version update.

However, There is a issue that stdout and stderr cannot be obtained.

The following code will not work. And, v2-beta.1 gives an error.

FileOpen("*", "w").writeLine("message")
FileOpen("**", "w").writeLine("message")

To avoid these, use the OutputDebug or debug directives instead.

OutputDebug, message
; @Debug-Output => message

[SAbboushi]

Great! I don't know the mechanics of how the attach will work e.g. I suspect vscode will be running and I attach frow within vscode. How will the configuration be selected i.e. when attaching, will there be a way to associate a specific workspace configuration to the version of AHK the script is running?

[zero-plusplus]

Normal debugging starts the debugger at startup, whereas attach starts the debugger later. After the debugger is started, it is the same as normal debugging. However, there are some limitations such as not being able to get stderr at present.

The Debug configuration is also the same as normal debugging. However, there are some differences in the following options.

• request: Must be specified as "attach"
• program: The path of the script that has already been executed and you want to attach. Unlike normal debugging, it cannot be omitted
• runtime: The path to AutoHotkey.exe to run the script that starts the debugger

[SAbboushi]

So if I understand correctly: 1) vscode must be running with a specific configuration already selected 2) we can only attach to a script that has been hardcoded into the selected configuration

[zero-plusplus]

That's right.

I noticed in your comment that technically the program can be attached even if it is not hardcoded. So I changed it so that if we omit program, it will automatically attach to the first script it finds that is running now.

However, I encountered the following issue. For example, SciTE4AutoHotkey runs the AutoHotkey script invisibly as an internal tool. If we try to attach it in this state, it will attach that script and we will have a issue where debugging of the expected script will not start.

If the user knows about it, it is not a issue, but if not, they will feel as if the Attach feature is broken.

For the above reasons, I will still make it so that only hard-coded scripts can be attached.

[zero-plusplus]

Latest information about attach.

• The issue with not being able to get stdout as explained above is probably my misunderstanding. It is currently only stderr messages that cannot be retrieved

Features of attach that are being considered.

1. Start debugging in launch mode if the target of the attach is not started
2. Lists the currently running scripts and attaches the selected script

I have a strong desire to implement the above features, but there are a few things to consider.

For example, if 1. is implemented in the attach mode, it will be upward compatible with the launch mode, and I fear that some people may use it without knowing the limitations of the attach mode. To avoid this problem, I can add an option in either launch or attach mode, but it will have a long and confusing option name like launchWhenNotRan.

For 2., you can show the executed script list when you omit program, and attach the selected script. You can skip the selection if there is only one the list.

[zero-plusplus]

I gave up on the implementation of 1. described above. because the restrictions and other specifications are complicated and difficult to explain. This, I thought, would not lead to user convenience.

2. is not yet reflected, but has already been implemented.

Please wait a little longer for the next release as I am still working on confirmation.

[Lexikos]

The solution to this is to get the stream from the pid in Node.js, but I can't find a way to do that at the moment

I don't think it is possible for an external process to redirect the standard streams of an already-running process. It would have to be done by calling SetStdHandle from within the process.

The issue with not being able to get stdout as explained above is probably my misunderstanding.

It looked like you understood correctly. The debugger doesn't redirect the actual stdout/stderr streams, only calls to FileAppend Text, * and OutputDebug, and warnings with StdOut mode. FileOpen always returns the actual streams (or dies trying), so is not redirected. Redirecting the File object or actual streams would be somewhat more complex than redirecting FileAppend/OutputDebug.