xplorer2 v.5.50.12 beta

[Kilmatead]

ps. actually try sending it a refresh command directly, it should work without tabbing

The trouble there is I need to know which pane is active to begin with (easier said than done when 3rd-party scripting), and is it a scrap pane, dual pane, scrap-window, or not? I think I tried that originally - if I just sent a refresh to everything in turn instead, this had a terrible response time as x2 would start rejigging foldersizes (before my magnificent fix, which you ignored), and that doubled up everything for waiting unpredictably on subsequent commands (like the selection restore).

I might have to give this a deeper revisiting.

[nikos]

I did actually check if the 33163 refreshes both panes in .12 since you admitted it was "probably an oversight", but apparently you didn't think to fix that one.

I saw a comment in my code from an earlier attempt to fix this "problem" and apparently something someplace else must have broken or I don't know. Memory is going down the drain lately

[otlaolap]

The trouble there is I need to know which pane is active to begin with (easier said than done when 3rd-party scripting), and is it a scrap pane, dual pane, scrap-window, or not? [ . . . ]

This specific thing is what adds the greatest amount of complexity and headache to my massive AutoHotkey pile in support of X2. The amount of labor to ascertain, or keep track of, which pane is active. And so I've been chastisably reluctant to try this new version.

[Kilmatead]

And so I've been chastisably reluctant to try this new version.

The only real difference (aside from the Options redesign/kerfuffle/débâcle/"gate") in this version which could interfere in this regard is the optional change in the addressbar (to the monstrously pointless and misnomer-ed "crumbs bar"). Since the addressbar is so intrinsic to effective 3rd-party scripting, just don't turn it off.

Curiously, by the way, the option related to it is in the Layout Settings section of the Advanced Settings Editor, and probably wins a prize for the most "informal" option label in English:

"Don't use fancy path crumbs bar, regular addressbar is fine"

...which has all the decision-making urgency of being trampled by a snuggle of rampaging sloths. It's "fine", is it now? Well, jolly-good then! Mind the door doesn't slap your arse on the way out, m'lady.

It's just weird. But very Nikos, at the same time.

It would be nice if those providing the upkeep on the translations could somehow capture the "blithely insouciant saunter" that word "fine" at the end of a sentence implies.

[nikos]

GetFocus().GetWindowText()=="left pane settings", easy
or control ID == 0xE900

[Kilmatead]

GetFocus().GetWindowText()...

That's only half the story dude, for if one clicks a toolbar button to invoke it, or is doing something else, while the pane "looks" active, and is active in our minds, it actually doesn't have the focus, so we need to get a little more creative...

This is the most reliable function I've crafted (using AutoIt, but AHK is the same thing without the formalities) that works under almost any conditions or, shall we say, at least fails the least...

Code: Select all

Global $hWin = WinActivate("[REGEXPCLASS:ATL:(Explorer)|(Scrap)Frame]")
Global Const $ADDRESSBAR = 1001
Global Const $INVOKE_ADDRESSBAR = 33131
Global Const $WM_COMMAND = 0x0111

Func _GetActivePane()
	Local $Focus = ControlGetFocus($hWin)

	If StringLeft($Focus, 19) = "ATL:BrowserListView" Then Return $Focus

	Local $AddressText = ControlGetText($hWin, "", $ADDRESSBAR)
	ControlSetText($hWin, "", $ADDRESSBAR, "") ; Applying a null string resets focus to the active-pane (regardless of where focus was originally)...
	_SendMessage($hWin, $WM_COMMAND, $INVOKE_ADDRESSBAR)
	ControlSetText($hWin, "", $ADDRESSBAR, $AddressText)

	Return ControlGetFocus($hWin) ; ...reading that new focus tells us which pane is the active-pane
EndFunc

It gets even goofier if you start taking the context of tab-enumeration into account, and deriving the (implied or actual) opposite pane, never mind the questions about control visibility and window "on-top-ness".

In a floating haze there's "Left pane settings", "Right pane settings", "Scrap view settings", "Scrap view dual settings"...

And then the real work begins, for after our dog has caught the car, what's he going to do with it...? Jaw clamped firmly on the bumper, his little paws start furiously swiping left and right and before you know it he's got a date for the doggy-prom... but that's another paradigm...

[nikos]

I don't think toolbar buttons steal focus... anyway
instead of testing strings, use GetDlgCtrlID and compare with 0xE900 for left (works for scraps too). For miniscrap check its ID with spy++

[Kilmatead]

I don't think toolbar buttons steal focus...

They don't usually, but I write many things that have preliminary popup context menus from said toolbar-button, and after that the world's gone dark.

I don't like testing strings either, but like I said, tabs... try determining if/which tabs are in play - depending on what you want to do, it gets messy. By no means impossible, just messy.

So when you go and change something randomly, we can hear a thousand voices scream horror into the abyss while you just turn your headphones up a little higher and bebop the days away...

[otlaolap]

[...] This is the most reliable function I've crafted (using AutoIt, but AHK is the same thing without the formalities) that works under almost any conditions or, shall we say, at least fails the least... [...]

My method works fine for me (at the moment) but it requires detecting pane acticvity and marking the active pane in one of Nikos' controls. I've preserved this simpler and encapsulated code in case I revisit my AutoHotkey pile some time in the future. The only question it raises, looking at it, is whether there are cases where restoring the address-bar contents to its previous non-blank state can cause activity of some sort -- possibly there was a command line lying there? -- but simply reloading the text should and likely does not cause anything else to happen except losing the insertion point position (too minute an effect to warrant any work to retain it or even this mention).

[Kilmatead]

Yeah, no I wasn't suggesting you mess with anything if what you do now works ("if it ain't broke..."). I imagine that you have a few AHK hotkeys which trigger x2 things (I replaced <Ctrl+F> for find, since Nikos won't let us), and since there's no way to predict where the focus might be when you use a hotkey, I found invoking the addressbar as blank to be the only real guarantee of active-pane-focus.

The only question it raises, looking at it, is whether there are cases where restoring the address-bar contents to its previous non-blank state can cause activity of some sort

I've never encountered an issue with it (I mainly added the content restoration for consistency, as it just looks weird when it's left empty), but nothing can happen without specific invokation. And if you need to use a hotkey while typing something into the addressbar, this way you can come back to it without losing anything.

I imagine that once upon a time (before user-configurable toolbars existed in x2) the addressbar was Nikos' developmental testbed solution for all functionality as it serves as an underappreciated command-line-cum-neighbourhood-grandmother-who-bakes-cookies-for-all-the-kids type of thingy and is bloody useful behind the scenes. As an aside, I don't know if you use Everything Search, but ES's search-bar is essentially x2's addressbar but so ramped-up on steroids it's approaching cardiac-arrest (since there are no toolbars to speak of). I mean it's completely insane, it can create bespoke custom columns integrated directly into the same search line, or conditionally modify any option at any time to serve that search. It's freakish.

Almost a pity Nikos didn't go similarly ape-sh*t with the addressbar, but I suppose then we wouldn't have toolbar functionality to complain about. And just for the record, any user who replaces the addressbar with that offensive crumbs nonsense is an apostate heathen philistine who must be immediately excommunicated and left to hellfire. Or just covered in honey and left in the hot sun for the ants-of-unusual-size to munch on, whichever seems more humiliating. (Too much?)

Anyway, I'm just musing...