Extremely strange behaviour

[glupost4]

So, I've used AHK for years and it helped me save 100's of hours of typing some stupid things. I'm not an advanced user of AHK even though I did use some interesting commands. BUT, lately, I'm having a big problem. I'm using Remote Desktop (RDP) and I connect to the remote PC, I do my stuff, I prepare ahk file, save it, reload it and it works. In Word or in Notepad or Excel (didn't try other programs). You'd say, so what, where is the problem ? The problem is that I have a program that I'm using for bookkeeping and that program happily accepted my AutoHotKey typing (it's actually mostly typing) and now it won't accept it. For example, I can use enter in that program, but if I use script, it won't move. Here is an example:

Code: Select all

^!a::
send {Enter}{Enter}{Enter}{Enter}{Enter}{Enter}{Enter}{Enter}{Enter}{Enter}{Enter}{Enter}{Enter}{Enter}{Enter}{Enter}{Enter}{Enter}{Enter}{Enter}{Enter}
return

I repeat.... It works in Notepad, Word, Excel.... Only in this program it doesn't work anymore. I'm stuck. I uninstalled, installed again, checked file associations, made it run as administrator, I've tried many things. As said, IT WORKS. But not in one particular program. How do I even find out where is the problem ?

[boiler]

When you say made it run as administrator, do you mean AutoHotkey itself, or the script? To have an effect, you need to run the script as administrator, no matter what privileges AHK or the Windows user has.

Also, your script can be reduced to this:

Code: Select all

^!a::send {Enter 21}

[keylo]

Try the following

Code: Select all

^!a::
WinActivate, the name of your program
WinWaitActive, the name of your program
send {Enter 21}

return

[lexikos]

I think boiler means to ask whether the bookkeeping program or the script is running as administrator.

It is not necessary to run the script as administrator; but doing so is one possible workaround for the problem described below.

When you say made it run as administrator, do you mean AutoHotkey itself, or the script? To have an effect, you need to run the script as administrator, no matter what privileges AHK or the Windows user has.

That's a little confusing. What's the difference between AutoHotkey itself and the (AutoHotkey) script? What privileges does AHK have when it's not running? If AHK isn't running, privileges are irrelevant. If AHK is launched by another process that was already running as administrator, AHK will inherit those privileges. What matters is that it has administrator privileges, not how it got them.

The problem boiler is alluding to is that if the target window's process is running at a higher integrity level than the script's process, a security feature known as User Interface Privilege Isolation will generally prevent the script's process from sending or intercepting keystrokes. In other words, if the target process is running as administrator, a script which is not running as administrator generally cannot send keystrokes to it.

The exception, as noted in the FAQ (How do I work around problems caused by User Account Control (UAC)?), is that "running with UI Access" allows the script process to circumvent these restrictions.

I'm using Remote Desktop (RDP)

Which system is running your script? I assume your bookkeeping program is running on the remote system, otherwise I can't imagine how your use of RDP is relevant.

If you have the RDP setting "Apply Windows key combinations" set to "On the remote computer" or "Only when using the full screen" (and you are using the full screen), the RDP client may install its own keyboard hook which takes precedence over any (previously installed) local hook. This prevents hotkeys from working if the script is running on the local computer. Possible solutions may include:

• Change the "Apply Windows key combinations" setting to "On this computer". This will, of course, also prevent Windows key combinations from being sent to the remote computer, so may not be ideal.
• "Reinstall" the keyboard hook after the RDP client window is activated (every time it is (re)activated, not just when it is launched), such as by suspending and unsuspending hotkeys or reloading the script.
• Run the script (or the relevant part of the script) on the remote computer instead of the local computer.