I've been using AutoHotkey with our work system made in Visual Basic, on windows 7 without any problems. For a few years now. Never any problems what so ever. A few of my script users recently upgraded to windows 10, and things are breaking.
I've tried the following.
1. Ran AutoHotkey script as administrator.
2. Enabled the Add 'Run with UI Access' to context menus option in AutoHotkey Setup and also tried running the script with that option.
3. Ran the visual basic program in administrator mode.
4. Turned UAC to lowest setting.
5. Verified the control names did not change.
6. Yes, we did reboot the computer.
The interesting thing is, ControlGetText can read text out of the edit fields, but cannot write with ControlSetText. These are fields that can be typed in so questions on that is not an issue either.
In the past, any issues I had that were suspected as UAC would be 100% working or 100% not. I am completely out of ideas as to why it appears to work on some commands and not others, on the same Control (ThunderRT6TextBox1) in the program.
Any help on this is highly appreciated. In a few months there is no question I will be moving to windows 10 on my machine. Unless we can get this figured out, it's doomsday.
Thanks.
Windows 10, Suspected UAC problem
Re: Windows 10, Suspected UAC problem
When I face this problem, I usually create an object(task without time) in the Windows Scheduler. Then I run that task from AHK.
Something like that .:(Seems to work well - I get no UAC question)
_ . - . _ . - . _ . - . _ . - . _ . - . _ . - . _ . - . _ . - . _ . - . _ . - . _ . - . _ . - . _ . - . _ . - . _ . - . _ . - . _
The example in the AHK Run Help is also working well (always you must answer yes - but you never forget to run the AHK-program as administrator)
_ . - . _ . - . _ . - . _ . - . _ . - . _ . - . _ . - . _ . - . _ . - . _ . - . _ . - . _ . - . _ . - . _ . - . _ . - . _ . - . _
Something like that .:
Code: Select all
ProgAHK = C:\Windows\System32\schtasks.exe /run /tn "%ScheduleName%"
Run %ProgAHK%,, Min UseErrorLevel
If ErrorLevel
....
_ . - . _ . - . _ . - . _ . - . _ . - . _ . - . _ . - . _ . - . _ . - . _ . - . _ . - . _ . - . _ . - . _ . - . _ . - . _ . - . _
The example in the AHK Run Help is also working well (always you must answer yes - but you never forget to run the AHK-program as administrator)
Code: Select all
full_command_line := DllCall("GetCommandLine", "str")
if not (A_IsAdmin or RegExMatch(full_command_line, " /restart(?!\S)"))
{
try
{
if A_IsCompiled
Run *RunAs "%A_ScriptFullPath%" /restart
else
Run *RunAs "%A_AhkPath%" /restart "%A_ScriptFullPath%"
}
ExitApp
}
MsgBox A_IsAdmin: %A_IsAdmin%`nCommand line: %full_command_line%
Re: Windows 10, Suspected UAC problem
Is this a compiled or uncompiled script? Is it the same version of AutoHotkey (version number, ANSI/Unicode, 32-bit/64-bit)?
N.B. Turning UAC to the lowest setting via Control Panel disables UAC on Windows 7, but on later versions all it does is disable the prompt that normally appears when a program tries to elevate. Programs still do not run at the highest integrity level by default.
N.B. Turning UAC to the lowest setting via Control Panel disables UAC on Windows 7, but on later versions all it does is disable the prompt that normally appears when a program tries to elevate. Programs still do not run at the highest integrity level by default.
Who is online
Users browsing this forum: mebelantikjaya, OrangeCat and 291 guests