Request that file paths be visible internally

[otlaolap]

I'd like a way for an external program to look at an Xplorer2 window and discover what file paths are actually active in the panes of the window.  Note that the window title does not give the needed information:  it reveals a current drive plus directory name, but not the full path from the root to the directory, and often I am editing several levels deep.

For my purposes, I have implemented some hacks to record this information.  First, I use AutoHotKey and intercept any change in window title to Xplorer2.  Window titles change when the user changes panes or changes directories.  At this time the edit box (the address bar) shows the current full path to the active pane (for me, because I rarely modify it).  So I can trap the active path at the time of a window title change.  But how to remember it in a way that sticks with the Xplorer2 window and pane?

What I do is record it in the text associated with an Xplorer2 internal control.  WinInspector shows the relevant part of the Xplorer2 control hierarchy as this:

    ATL:ExplorerFrame
        WTL_SplitterWindow2
            WTL_SplitterWindow2
                WTL_PaneContainer2 [ for one pane]
                    subportions of the pane
                WTL_PaneContainer2 [ for the other pane]
                    subportions of the pane

What works for me is recording the active path in the text part of the WTL_PaneContainer2 that is showing the pane.  Thereafter, when I walk the control hierachy, I can see the pane and what path the pane is displaying.  Then the automated tools can go to work.

I also record, in that same place, which is the active pane (although it might have made more sense to put this in the WTL_SplitterWindow2 text).

I advocate that Xplorer2 place the path of the pane into the internal WTL_PaneContainer2 control, just like it writes the path into the visible external pane in the pane's title bar.  The control's text would then mirror what is printed on the control's titlebar.  And the next control upward could show which of the two panes is active.

Thanks.

[nikos]

i remember i did a special message for dirkey once upon a time

// one for the dirkey guy; return CONST active pidl. LP/WP unused
#define UWM_GETDIRECTORY (WM_APP + 31)

so you can activate each view in turn and query it for its folder

however if you want to do any fancy stuff you're better off with WSH

[snakebyte]

I'd like a way for an external program to look at an Xplorer2 window and discover what file paths are actually active in the panes of the window.  Note that the window title does not give the needed information:  it reveals a current drive plus directory name, but not the full path from the root to the directory, and often I am editing several levels deep.

Why can't you get the path off the address bar? I've been using following Autohotkey code in many of my scripts.

Code: Select all

ControlGetText, path, Edit1, ahk_class ATL:ExplorerFrame
Msgbox %path%

[otlaolap]

I do trap the path from the edit box, using exactly the same statement as you suggest (only the name of  the variable is different).  My original second paragraph was meant to say this.  This trapped path is what I record in the WTL_PaneContainer2 control text.  

But what path is active in the other pane?  My thought is simply that the path active in the pane, for each pane, be recorded by Xplorer2 itself as the path in the pane changes.

(Just as it would be very hard to work without Xplorer2, it would be stressfully unsatisfying to work without AutoHotKey.)

[snakebyte]

But what path is active in the other pane?  My thought is simply that the path active in the pane, for each pane, be recorded by Xplorer2 itself as the path in the pane changes.

Yes, Xplorer2 is not automation friendly and you have to resort to hacks to get things done.

I use following code to extract active and inactive paths

Code: Select all

; Read active path 
ControlGetText, activepath, Edit1, ahk_class ATL:ExplorerFrame
sleep 100
; Switch to inactive pane
SendMessage, 0x0111 , 32857 , 0, ,ahk_class ATL:ExplorerFrame
sleep 100
; Read inactive path 
ControlGetText, inactivepath, Edit1, ahk_class ATL:ExplorerFrame
sleep 100
; Switch back to previous active pane
SendMessage, 0x0111 , 32857 , 0, ,ahk_class ATL:ExplorerFrame

If you are launching your script as user command from X2, then you can also pass $I parameter to your script to read the inactive path without switching panes.

For my scripts, even I'm looking for a way to find index of current active tab and a way to switch to particular tab by index. I have some hackish workarounds for this but they could have been much more elegant if X2 had better automation story.

[otlaolap]

I'm happy with my hack, as a hack, which records the path active in a pane at the time Xplorer2 loads it into the pane, records which pane is active, and records this info within Xplorer2 itself.

To execute commands from within X2, I use a mediating command.  It sends a hotkey to X2 that causes X2 to run a program that writes the standard pane-and-path $ tokens for both panes to the registry; it waits until the registry is written; and then it interprets its arguments -- a standard command line with $ tokens.  The tokens are replaced and the command is run.  This allows me to define the cusomized commands outside of X2 and not have to add them to X2's hot-key commands.  All of this is an offshoot of posts and suggestions here written by you, but I cannot point now directly them.  I studied them a lot when I first bought X2.

In addition, I have written menu augmentation code that I use on top of X2's menus.  X2's menus stay visible and are accessable through the mouse (hardly ever use them), but the ctrl- and alt- key strokes get me what I want directly.  In Visual Basic I wrote a program that allows virtually complete customization of the Xplorer2 hotkeys (move 'em anywhere, use any of the 5-digit message codes I can find in the manual or in the resource menus defined within X2, call external macros, and so on).  The resulting keystroke patterns make better sense to my fingers for me.

These 5-digit numbers can also be sent as needed by other external commands.

The original idea of this thread was simply to make a small suggestion to Nikos that might make automation a bit easier for folks.