[Question] [Enhancement] How debug v1 and v2 scripts when both use same ".ahk" extension

[SAbboushi]

I believe that AHK V2 (default) standard file extension is ".ahk".

Although other extension can be used, I don't find a solution that doesn't cause failure.

• .ahk2 causes problems re: 8.3 short file name
• Using an extension other than ".ahk" breaks Libraries of Functions: Standard Library and User Library
• AHK v2 Library Functions only work with .ahk extensions

And it seems to me there are no solutions unless lexikos decides to support alternate extensions.

@TheArkive wrote a script to switch between versions, but that means only editing/debugging one version at a time

My situation: I use ".ahk" extension for both v1 and v2 files primarily because of my Library Functions.

The best solution I can think of to allow debugging both v1 and v2 scripts at same time: Also allow your extension to chose AHK executable based upon folders: I suspect it is common that v1 scripts are in different folders than v2 scripts. Is possible to do something like this in launch.json:

"v1_extensions": "ahk", "v2_extensions": "ahk, ahk2, ah2", // ability to configure for those with custom extensions "runtime_v1": "AutoHotkey.exe", "runtime_v2": "v2/AutoHotkey.exe", "v1_folders": "d:\AHKv1, d:\TestScripts\AHKv1, d:\AHK_Libraries\AHKv1", "v2_folders": "d:\AHKv2, d:\TestScripts\AHKv2, d:\AHK_Libraries\AHKv2",

Or is there a better way? I'm still studying how vscode's launch.json file works, so maybe I am not seeing a better way yet.

Also, I don't understand the usage of setting: "type": "ahk"?

[zero-plusplus]

Do you want the extension to be ahk because you want to load a script using a function library? If there is no other reason, you can solve it by loading the script and changing the extension to ahk2 or ah2 without using the function library.

The strange thing is that the v1/v2_folder example clearly doesn't seem to use the function library.

Could you please tell me a little more about the reason for making the extension ahk?

Also, "type": "ahk" indicates the debugger to use, not the extension. I regret that I should have used autohotkey, but currently changing this breaks the debugger.

[SAbboushi]

Do you want the extension to be ahk because you want to load a script using a function library?

I am not sure I understand your question; hopefully this will clarify:

test.ahk: myFunction(12)

This one line script will work if I have a second script -- a library script -- named myfunction.ahk located in any of three folders:

myFunction.ahk:

myFunction( var )
{
    msgbox var
}

This will only work for library scripts that have extension ".ahk". I have over 150 library scripts and add more regularly.

The strange thing is that the v1/v2_folder example clearly doesn't seem to use the function library.

In my example: My v1 library scripts are located in "d:\AHK_Libraries\AHKv1" My v2 library scripts are located in "d:\AHK_Libraries\AHKv2"

Ah! Maybe I should have explained that I have a "Lib" junction under AHK executables pointing to those libraries:

e.g. J:\AHK\AutoHotkey.exe J:\AHK\Lib --> Junction to "d:\AHK_Libraries\AHKv1" J:\AHK\v2\AutoHotkey.exe J:\AHK\v2\Lib --> Junction to "d:\AHK_Libraries\AHKv2"

Was this the cause of confusion? If not, please clarify.

By the way: I am SO SO HAPPY with your extension!

[zero-plusplus]

I am very happy!

By the way: I am SO SO HAPPY with your extension!

I rewrote the text several times and forgot to write that the translation wasn't working. I couldn't read the intention as you said.

I understand why you use ahk for the library extension.

Before I say my idea, I would like to ask you, can't you solve it by making the extension of the main file that uses the library ahk2?

[SAbboushi]

can't you solve it by making the extension of the main file that uses the library ahk2?

I think this would be a partial solution: the problem is when I create/modify/test library functions, I am running the script alone. e.g.

myFunction.ahk:

; Test data:
x:= myFunction(12)

; LIBRARY FUNCTION:
myFunction( var )
{
    msgbox var
}

With what you proposed, I would need to have a separate test script for each library function and edit both scripts while developing/testing/modifying the library script which is not my preference.

[SAbboushi]

Also, I think this would introduce another problem: how would I control which language support extension is used when I'm editing .ahk files as now I would have both v1 scripts and v2 Library Scripts using same extension...?

[zero-plusplus]

The settings of vscode can be changed for each workspace (folder). And there is a setting that determines which language the extension is treated as. In other words, you can control whether to treat ahk as v1 or v2.

The concrete solution is to set the following file in J:\AHK\v2\.vscode and open that folder with vscode. (When using dudelmoser.vscode-autohotkey2)

settings.json
{
     "files.associations": {
         "*.ahk": "ah2",
     },
}

[SAbboushi]

Thanks

I am able to debug AHKv1 and AHKv2 scripts that all use ".ahk" extension and that use the correct language support file.

Is it possible to debug both at same time in two vscode instances?

My current configuration:

I have created two multi-root Workspaces: AHKv1.code-workspace and AHKv2.code-workspace.

Each Workspace has their own folders of the matching AHK version scripts. For running AHK V2 scripts, I open the appropriate Workspace (File>Open Workspace).

AHKv1.code-workspace:

{
    "folders": [
        {
            "name": "AHK LibV1",
            "path": "D:\\Documents\\AutoHotkey\\LibV1"
        },
        {
            "name": "AHK V1 Examples",
            "path": "D:\\Documents\\Application Data\\AutoHotkey\\AHK SA Examples\\AHK v1"
        }
    ],
    "settings": {
        "files.exclude": {
            "**/*.bak": true
        }
    }
}

AHKv2.code-workspace:

{
    "folders": [
        {
            "name": "MasterAHK scripts",
            "path": "..\\..\\..\\..\\..\\..\\..\\Documents\\Application Data\\AutoHotkey"
        },
        {
            "name": "AHK LibV2",
            "path": "D:\\Documents\\AutoHotkey\\LibV2"
        },
        {
            "name": "AHK V2 Examples",
            "path": "D:\\Documents\\Application Data\\AutoHotkey\\AHK SA Examples\\AHK v2"
        }
    ],
    "settings": {
        "files.exclude": {
            "**/*.bak": true,
            "**/*.ico": true,
            "**/*.png": true,
            "**/*.PNG": true
        }
    }
}

Each Workspace also has one launch.json file. Even though I have multi-root Workspaces, it seems only one of the folders needs a launch.json file.

D:\Documents\AutoHotkey\LibV1\.vscode\launch.json:

{
    // 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": [
        {
            "name": "AutoHotkey Debug",
            "request": "launch",
            "type": "ahk",  // identifies the debugger
            "runtime": "J:/StandaloneApps/AutoHotkeyV1/AutoHotkeyU64.exe",
            "program": "${file}",
            "args": [],
            "stopOnEntry": false,
            "useAdvancedBreakpoint": true,
            "useAdvancedOutput": true,
            "maxChildren": 10000 //
            // "internalConsoleOptions": "openOnSessionStart"
        }

    ]
}

D:\Documents\AutoHotkey\LibV2\.vscode\launch.json:

{
    // 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": [
        {
            "name": "AutoHotkey Debug",
            "request": "launch",
            "type": "ahk",  // identifies the debugger
            "runtime": "J:/StandaloneApps/AutoHotkeyV2/AutoHotkeyU64.exe",
            "program": "${file}",
            "args": [],
            "stopOnEntry": false,
            "useAdvancedBreakpoint": true,
            "useAdvancedOutput": true,
            "maxChildren": 10000 //
            // "internalConsoleOptions": "openOnSessionStart"
        }

    ]
}

I used option to disable language support extensions by Workspace:

• AHKv1.code-workspace: Extensions>AutoHotkey>Settings (gear)>Disable (Workspace)
• AHKv2.code-workspace: Extensions>AutoHotkey 2 (alpha)>Settings (gear)>Disable (Workspace)

I can keep two vscode instances open: one with AHK V1 Workspace and the other with AHK V2 Workspaces. But I can only debug one at a time. Any workaround?

By the way, I suspect you did not learn anything new from my post but I hope it might be helpful if you want to explain in English to someone else how to do this.

[zero-plusplus]

I confirmed, but it is probably impossible due to the specifications.

If you are running an AutoHotkey in debug mode and you start another AutoHotkey in debug mode, it will not work. It just runs the script.

I'm guessing that SciTE4AutoHotkey is a single instance, so it shouldn't be supposed to be debugged by multiple instances. So I think it is not implemented.

[SAbboushi]

Hmmm... I just tested again:

• I can run two instances of SciTE4AutoHotkey and debug two scripts concurrently
• I can run one instances of SciTE4AutoHotkey and one instance of vscode and debug two scripts concurrently
• I cannot run two instances of vscode and debug two scripts concurrently (one instance terminates other instance script and writes OutputDebug to wrong (i.e. the terminated script's) DEBUG CONSOLE.

[SAbboushi]

I can provide details on running two debug sessions tomorrow if you want (I'm tired now... going to bed!)

[zero-plusplus]

I learned for the first time how to make scite multiple instances.

When I tried it, the following behavior was shown.

1. When debugging in the order of scite -> scite, debugging does not start
2. When debugging in the order of scite -> vscode, It can be successfully debugged
3. When debugging in the order of vscode -> vscode, debugging is not started and the script is simply executed.
4. When debugging in the order of vscode -> scite is in order, the same operation as in 3.

I debugged the extension and confirmed the behavior, but the stage when AutoHotkey was executed Is causing the behavior of 3. so I don't know how to prevent this.

[zero-plusplus]

I was able to resolve this issue by using a different port (for each workspace). The port can be set in the port of launch.json.

I can solve this problem automatically, but in that case it means that using a port number that the user did not intend, so I suspect that you may have a security problem.

So I'll just update the port description in the next version.

[zero-plusplus]

Changed to display a message asking whether to debug using another port. This change allows you to debug multiple files without editing launch.json.

However, if the message gets in the way, you need to edit launch.json.

Please check.

[SAbboushi]

Sorry - I was too tired last night to provide more details.

I use portable version of SciTE4AutoHotkey. I have a folder for AHKV1 and another for AHKV2 that contains AHK code and SciTE subfolders: AHKV2 | --SciTE

AHKV2 | --SciTE

In order to run two instances of SciTE4AutoHotkey and run debugger:

• First instance of SciTE4AutoHotkey needs to be run in elevated mode (i.e. Run as Administrator)
• Second instance is run non-elevated.
• The instances must be different SciTE.exe files from different folders such as my example folder structure above.

This allows running two different versions of AHK:

• v1 and v2
• two different versions of v1
• two different versions of v2

Note: fincs said that running SciTE4AutoHotkey as admin is not supported:

...the way the portable version does the ProgID registering does not work when the program is run as admin.

I wondered whether this is why wrong vscode DEBUG CONSOLE was written to when I was testing multiple debugger sessions.

Additionally, non-admin programs will never be allowed by Windows to use admin programs' COM objects due to security reasons. I never understood what he meant... which "non-admin programs"...?

---

Your solution for multiple debugging sessions using vscode and prompting for port #:

EXCELLENT EXCELLENT EXCELLENT!!!

YOU ARE VERY VERY AMAZING!!! Thank you for your great work!

[SAbboushi]

I discovered the "Duplicate Workspace in New Window" command, so now I can have multiple concurrent debug sessions per workspace. VERY VERY NICE!

But I find another challenge: I need to run one instance of vscode debugger elevated. It seems vscode will not allow another vscode instance if an elevated instance is already running. It seems vscode will not allow creating an elevated instance if a non-elevated instance is running. Since I am running vscode portable, the solution I found: I must have a duplicate vscode app folder so I can run vscode.exe from one folder elevated and run vscode.exe from second folder non-elevated (or elevated). I have a junction from second folder to vscode settings of first folder, so they share the same settings and workspace.

If you think of better way, please let me know. Also, please note my earlier post above.

[zero-plusplus]

Unfortunately, I will solve this problem in the same way as you. I think there is no other way than to prepare another vscode.exe.

[SAbboushi]

I find it strange: when launching vscode as admin, I can then do "Duplicate Workspace in New Window" and have additional instances using same vscode.exe, so mysterious to me why cannot have unelevated vscode.exe and elevated (same) vscode.exe....??

Anyway, for now I agree: prepare another vscode.exe

[zero-plusplus]

I think the vscode created by "Duplicate Workspace in New Window" is in a elevated state.

[SAbboushi]

Yes: If vscode is in elevated mode, "Duplicate Workspace in New Window" creates additional elevated vscode instances.

If vscode is in non-elevated mode, "Duplicate Workspace in New Window" creates additional non-elevated vscode instances.

So it appears to me that vscode has no problems handling multiple instances in either elevated or non-elevated mode. So I find it mysterious that it would have a problem handling mixture of elevated and non-elevated instances of same vscode.exe...?

[zero-plusplus]

Probably a security issue.

I think that using the same exe is sharing the system such as some settings and processing.

The fact that you can use the same system with different permissions means, for example, that you can operate a file that you cannot operate without permission from an unauthorized instance.

Therefore, I think that such restrictions are imposed.

[SAbboushi]

Thank your for your explanation. That makes sense