Feature suggestion - Window Administrator

[DougalScott]

When using the Window, Administrator menu selection, can the new instance open the active and inactive panes to the current folders please. Currently (3.0.0.4 ULT), the active pane is remembered, but the inactive pane changes to the default second pane folder (what comes up when X2 is first opened). I often need to change to an admin instance to copy/delete/move files in and out of protected folders, and having to reset the target folder each time is a pita.
Cheers

[nikos]

you can first do ACTIONS > SAVE SETTINGS NOW then launch the admin window. I'll see if that can be done automatically

[otlaolap]

I think you likely should propagate the original window's /R command line option to the newly-opened Administrator window as well. This option restricts the browser instance to explore only within a user-specified scope, and that same scope should apply to the Administrator window opened from the browser instance.

[DougalScott]

you can first do ACTIONS > SAVE SETTINGS NOW then launch the admin window. I'll see if that can be done automatically

I would rather not do it that way, I have Save settings on exit off specifically so when I open X2 it starts at the same place each time.
Cheers

[FrizzleFry]

Grab the Elevation Toolkit from here, put Elevate64 somewhere convenient, set up a user command like this...

>C:\tools\Elevate64.exe C:\tools\xplorer2_ultimate\xplorer2_64.exe /P "$L" "$R"

adjust paths as necessary and put it on a toolbar...

make sure you use the /P switch or the new x2 window will not be elevated (run as admin)

[DougalScott]

Thanks, that works, and I have an equivalent AHK exe I created. However I want to be able to use the same command with both installed X2 at C:\Program Files\zabkat\Xplorer2_UC and portable at X:\Portable Apps\Xplorer2.
When I try to use the x2dir env variable, it isn't available when using > with an exe eg > %x2dir%Xplorer2_64.exe doesn't work, and including %x2dir% as a command parameter doesn't work either. The x2dir env var only appears if using $ to launch commands, but then you get the Xplorer2 command window and need to close it, or a DOS command window if not using the X2 console and need to close it or include & exit to the command and have an ugly command window in the background during the UAC prompt.
Is there anyway to determine where X2 resides when using the > command prefix, other than testing a bunch of potential x86/x64/portable locations, which may or may not find the one that the command was launched from with my USB tools drives attached I might have more than 4 folders with x2.
Only solution I have found is to use AutoHotKey and get the path of the active window on launch to determine where X2 that called the command resides.

[Kilmatead]

If the expanded path includes spaces (such as your "X:\Portable Apps\Xplorer2"), you must surround the %X2DIR% variable with double-quotes, i.e., define the user-command as:

> "%x2dir%Xplorer2_64.exe" [...]

It probably worked for you under DOS ($) because the path segment "Portable Apps" would have been auto-converted into 8.3 format ("X:\PORTAB~1\..."), thus making the <space> character irrelevant. Win32 (>) does not do any path conversions.

Also, remember that the environmental variable is only available when x2 is already running, so it won't work for cold launching - but within user-commands it works fine, be they "$" or ">" defined.

[DougalScott]

I swear I spent ages testing the output of

Code: Select all

> "%x2dir%Xplorer2Admin.exe" "$L" "$R"

and it only ever worked when I was starting from the x2dir folder (where I had my exe to relaunch as admin). I captured and output the command parameters of

Code: Select all

> "%x2dir%Xplorer2Admin.exe" "%x2dir%" "$L" "$R"

and the first parameter was always empty.
But now it works as expected so I can give up more the ugly

Code: Select all

> cmd.exe /c "start """" "%x2dir%Xplorer2Admin.exe" "$L" "$R""

workaround.
Thanks for pointing out that X2 does actually work the way it is supposed to.