Run AHK from within elevated X2 doesn't work; run standalone and works

Discussion & Support for xplorer² professional

Moderators: fgagnon, nikos, Site Mods

Post Reply
Caveatrob
Member
Member
Posts: 40
Joined: 2008 Aug 01, 18:07

Run AHK from within elevated X2 doesn't work; run standalone and works

Post by Caveatrob »

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.
Kilmatead
Platinum Member
Platinum Member
Posts: 4580
Joined: 2008 Sep 30, 06:52
Location: Dublin

Re: Run AHK from within elevated X2 doesn't work; run standalone and works

Post by Kilmatead »

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...)
Caveatrob
Member
Member
Posts: 40
Joined: 2008 Aug 01, 18:07

Re: Run AHK from within elevated X2 doesn't work; run standalone and works

Post by Caveatrob »

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:

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%
	}
}
Kilmatead
Platinum Member
Platinum Member
Posts: 4580
Joined: 2008 Sep 30, 06:52
Location: Dublin

Re: Run AHK from within elevated X2 doesn't work; run standalone and works

Post by Kilmatead »

Caveatrob wrote: 2017 Jan 16, 23:01It stops at the file loop before it goes in, apparently.
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. :wink:

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.
Post Reply