Running an AHK script as a User Command in XPlorer2 that just does some simple file loops and the loops don't run when invoked from an elevated xPlorer2. Procexp shows the script running as High integrity. When I run the script outside of XPlorer2, script shows again as High integrity (elevated) and runs just fine.
I'm trying to understand why running X2 as admin and then invoking an AHK script doesn't work with UAC enabled in Windows 7, but the script runs by itself just fine otherwise.
Can someone break this down? I've read through the forums here and with AHK and still don't quite understand why elevation isn't firing properly when an elevated X2 runs a usercommand.
Run AHK from within elevated X2 doesn't work; run standalone and works
Moderators: fgagnon, nikos, Site Mods
Re: Run AHK from within elevated X2 doesn't work; run standalone and works
Need a little more information: Is this a pre-compiled script, or generic (launched through the AHK runtime)? Does it rely upon (or assume) a current working directory? What exactly is the user-command that launches it? And, just for good measure, how do you know it's not working? Bad results, crashing/hanging, unexpected behaviour?
Have you successfully launched other scripts via a user-command, or does this happen with everything? Does it work from an un-elevated x2?
(Sorry for all the questions, but otherwise it's a guessing game...)
Have you successfully launched other scripts via a user-command, or does this happen with everything? Does it work from an un-elevated x2?
(Sorry for all the questions, but otherwise it's a guessing game...)
Re: Run AHK from within elevated X2 doesn't work; run standalone and works
Generic, launched by caling autohotkey.exe through MENU++ though I've also tried launching it as a standalone User Command (autohotkey.exe c:\scriptpath\script.ahk)
It stops at the file loop before it goes in, apparently. I know it doesn't work because the files aren't changed/renamed when run via X2 and they are changed/renamed when run outside of X2 from Windows Explorer. All processes show "High" integrity in ProcExp, which indicates running elevated as far as I recall.
Tried looking at ProcMon output, but nothing jumps out as "access denied."
Relevant code:
It stops at the file loop before it goes in, apparently. I know it doesn't work because the files aren't changed/renamed when run via X2 and they are changed/renamed when run outside of X2 from Windows Explorer. All processes show "High" integrity in ProcExp, which indicates running elevated as far as I recall.
Tried looking at ProcMon output, but nothing jumps out as "access denied."
Relevant code:
Code: Select all
Loop Files, %InputFolder%\*.*
{
msgbox %A_loopfilelongpath%
SplitPath, A_LoopFileLongPath, OutFileName, OutDir, Ext, File_No_Ext, OutDrive
; MsgBox OutFileName - %OutFileName%`nOutDir - %OutDir%`nExt - %Ext%`nFile_No_Ext - %File_No_Ext%`nOutDrive-%OutDrive%
;/* --- rename or refactor the base name if required --- */
;Base_New:=RegExReplace(File_No_Ext, "[ ]*\([0-9]+\)[ ]*$", "")
Base_New:=File_No_Ext
FileGetTime, FileModificationDate, %A_LoopFileFullPath%, M
FileDate=%FileModificationDate%
FormatTime, FileDateYYYYMMDD, %FileDate%, yyyy'-'MM'-'dd
FileMove, %A_LoopFileFullPath%, %OutDir%\%FileDateYYYYMMDD% - %Base_New%.%ext%
}
}
Re: Run AHK from within elevated X2 doesn't work; run standalone and works
It's the "apparently" part that stands out - obviously the script is executing for you, but are the parameters passed correctly from x2? You have one msgbox within this loop as shown, but are there others (previous to the loop) that show the received import/export paths are actually correct? I would doubt this is an integrity issue, unless you first verify that the paths are correct and/or trap your functions for errors. Liberal use of msgbox's is always recommended for debugging.
While I do not use AHK specifically, I have written hundreds of AutoIt scripts which are essentially the same thing, and it's usually the user-command which is the problem. If you are using relative paths or "assuming" a current-working directory (never a good idea), try un-checking Tools -> Options -> Advanced -> Don't Lock Browsed Folder.
But without a full script to test (or at least the literal text of the user-command), it's still hard to say where the problem is.