Script not working on another user's computer - could it be language?

[kyguypi]

I wrote a v2 script that works great on my computer. A colleague downloaded it, I walked them through installation and ensured it's running on the same v2 64 interpreter. The hotstrings in the script are running, but the hotkeys aren't.
I'm not sure what's causing the issue, and I'm troubleshooting via a screenshare. The colleague is in a different country, and their primary language is spanish (mine is english). I'm wondering if their language settings could be affecting the execution of the script.

I've tried searching for answers, but keep finding things related to hotkeys to get spanish accents on an english keyboard. Thanks!

[mikeyww]

Welcome to this AutoHotkey forum!

It's possible, depending on your script. A suggestion for posting in the forum is to include the script that is not working.

[kyguypi]

Thanks! That's a good suggestion.

Example hot keys are:

Code: Select all

~- & 1::
{
    Send "!sc"
    Sleep 100
    Send "FUTURE"
    Send "!d"
    Send month "/1/" A_YYYY
    Send "{Enter}"
}

... and ...

#HotIf GetKeyState("Ctrl") and GetKeyState("Alt")
~f & g::
{
    Send "!sc"
    Sleep 100
    Send "FUP-GEN"
    Send "!d"
    Send "3d"
    Send "{Enter}"
}

It appears, though I'm not certain, that the "!d" part is firing correctly, but not "!sc".


[Mod edit: Added [code][/code] tags. Please use them yourself when posting code.]

[mikeyww]

As noted in the documentation, AHK does not necessarily support more than two keys in a custom combination. Results may vary. You can isolate your problem by shortening your script to a single line. This would be a hotkey such as F3 that sends Alt+S+C. That is the starting point. If it works, change to a custom combination. If that works, you can add the directive. Test iteratively. If your first script fails, then you know exactly which line was the problem, because the script has only one line. If the keyboard has an AltGr key, then sometimes the desire is handling it. The documentation explains that key as well.

If the first script fails, then there is no point adding another 12 lines until the original problem is solved. Feel free to post again if you get stuck.

[kyguypi]

Thanks! After a lot of debugging, the hotkeys are all correctly firing. What's happening is during the execution. Specifically, during 'Send "!sc"'. On my computer, in this application, that opens a menu (Alt s) and then selects an option (c). I've sent the script in many many forms - Send, Send Input, Blind, Send "{Alt}s" Send {"Alt down}s" Send {Alt down}c" etc. I've added several seconds of sleep and removed it. What happens on the other person's computer is exactly what would happen on my computer if after !s, I clicked out of the menu. The !c that follows !s is opening a separate menu in the window's main context, not selecting the item in the menu that is already open.

Any ideas why?

[mikeyww]

Would try something like this, with no other code.

Code: Select all

#Requires AutoHotkey v2.0
F3:: {
 SetKeyDelay 25, 25
 SendEvent '{Alt down}sc{Alt up}'
 SoundBeep 1500
}

[RussF]

In your script,

Code: Select all

Send "!sc"

will send Alt-s and then c (NOT Alt-c). This is fine, as most standard Windows menus will respond by opening the main level window that responds to Alt-s and then select the first menu item that begins with c. If this happens to be a sub-menu, that sub-menu will open. If it is a command, and it is the only command that starts with c or there is a command with an underlined c, then that command will execute. If there are multiple commands that start with c and none of them are underlined, Windows will pause at that item and allow you press c again to go to the next one, or Enter to select it.

If the remote application is following the Spanish language setting within the menus, it is possible that the menu item starting with c on that system is not the same menu item on your system.

For example (and I'm just guessing here) "File/Open" in English would be "Archivo/Abierto" in Spanish. On one, you would use Alt-f o and the other would be Alt-a a.

Again, this is purely conjecture and I may be all wet, but I would closely examine the menu structures on both systems.

Russ

[mikeyww]

Thank you, Russ. I had assumed that this had already been assessed, but perhaps not!

[RussF]

Yeah Mike, I thought so as well until I saw

...!s is opening a separate menu in the window's main context, not selecting the item in the menu that is already open.

which led me to believe the menu option the OP wants isn't triggered by the same keys on the Spanish version.

That said, if the menu structure is identical on both systems, well, we're back to square one.

Russ

[kyguypi]

Thanks! I had considered that, but the application we're in is ancient and only has an english version. Also - on video calls, I've had him input these inputs by hand on his keyboard, and that works as expected. We've tried "!sc" but also "!s" then "!c" on a separate line, and again with Sleep 2000 between them. It's extra frustrating, because I keep thinking it must be user error. It has to be. So I keep checking on him - are you reallly replacing the running version? Are you not clicking anything else?

The item triggered by "c" is also the first thing in the menu when you hit "!s", so the most recent version I sent had:

SendEvent "!s"
Sleep 1000
SendEvent "{Enter}"

I've also used Send and SendInput, all the same. They all work on my machine, but for him, the {Enter} isn't registering. It's as though all of the commands are going to the one window, regardless of the other one opening. "!c" does the same thing it would have done if you had never sent "!s". "!s" opens the menu, visually, but the context for how future input is interpreted doesn't change. But it works if he does it himself.

One last issue - and this may be the cause - we're doing this through a remote desktop. It's a remote application - same on my computer as on his. Functionally, it seems to work as though it were running on my machine, but it's running remotely. The does add a layer between the immediate input and the output, though.

[RussF]

I do a lot of remote work via VNC and I discovered early on (as I'm sure you have), that if you have any local hotkeys defined that are the same as hotkeys defined on the remote system, the local ones will take precedence, so I have to make sure I don't have any duplicates running locally. However, if you're having the person sitting at the remote keyboard initiating those hotkeys, it shouldn't make any difference.

You need to determine if, at the remote end, the problem is the system, the particular application, or your script.

Testing the system is easy. Make sure no other scripts are running and launch the following script:

Code: Select all

#Requires AutoHotkey v2.0+

f9::{
    A_Clipboard := "This is a test"
    Send "!ep"
Return
}

f10::Exitapp

Then launch an instance of Notepad and press F9. If "This is a test" appears in the edit window, you know it is not the system.

Next, create a separate stand-alone script with only the !sc command attached to a hotkey and enough code after that to ensure it works. Launch that script and then launch the app in question and press the hotkey. If it works, then you know it isn't the app, but your script, and a detailed analysis of your script is required.

This can all be done remotely as long as you don't use a hotkey that is the same as one on your local system. This way, you aren't burdening your remote user to sit at the keyboard while you test.

Try these (if you haven't already) and post your findings. You could also post your script for other eyes to scrutinize. While I am still becoming acquainted with V2, others here have more experience with it and may be able to help.

Russ

[mikeyww]

I recommend using ClipWait.

Although Return causes no harm at the end of a function, it is not required, because the function always returns at its conclusion.

[RussF]

I recommend using ClipWait.

Yup, had it in my head when I was writing it, but must have gotten distracted and forgot to include it.

Although Return causes no harm at the end of a function, it is not required, because the function always returns at its conclusion.

Old habits die hard . As I said, still learning the nuances of V2. At the same time, I like to use a Return for my own self-documentation. Also, while there are as many opinions out there as there are programmers, I subscribe to the "One entry point - one exit point" method of coding functions rather than sprinkling Returns throughout a function, especially if it returns a value. Either way is neither right nor wrong - it's simply a matter of personal preference. I digress...

Thank you though, Mike, your input is always valued.

Adapted script:

Code: Select all

#Requires AutoHotkey v2.0+

f9::{
    A_Clipboard := "This is a test"
    ClipWait(1)
    Send "!ep"
}

f10::Exitapp

Russ

[mikeyww]

First, I recommend clearing the clipboard before setting it. If the clipboard is already populated, then ClipWait will have no effect.

Second, I recommend checking the value of the ClipWait function when ClipWait is used. This function returns 0 (false) if the function timed out.

An example of how to use ClipWait properly is cited below.

https://www.autohotkey.com/docs/v2/lib/ClipWait.htm#ExBasic

This example demonstrates both of the recommendations.

[RussF]

First, I recommend clearing the clipboard before setting it. If the clipboard is already populated, then ClipWait will have no effect.

I agree, IF I were using Windows' copy function (Ctrl-c) to populate the clipboard - as in the link you posted:

Code: Select all

A_Clipboard := "" ; Empty the clipboard
Send "^c"
if !ClipWait(2)
{
    MsgBox "The attempt to copy text onto the clipboard failed."
    return
}
MsgBox "clipboard = " A_Clipboard
return

Notice that there is no call to ClipWait after setting A_Clipboard to "". Why? is A_Clipboard := "" instantaneous, but A_Clipboard := "This is a test" is not? I posit that they are identical and that there is no need for ClipWait unless you are using Ctrl-c to populate the clipboard.

Nevertheless, I was simply providing the OP with a quick and dirty method for testing the problem that was posted, which didn't have anything to do with the clipboard anyway.

Russ

[mikeyww]

Russ, in looking back at the issue, as far as I know, you are correct. I have not tested setting the clipboard to a longer string or a bunch of binary data, to see whether that takes longer. I imagine that you are right even in those cases.