Search within selected folders

Discussion & Support for xplorer² professional

Moderators: fgagnon, nikos, Site Mods

richardk
Silver Member
Silver Member
Posts: 178
Joined: 2007 Mar 27, 18:26

Re: Search within selected folders

Post by richardk »

dunno wrote:
otlaolap wrote: what do I want? Highlight some Items and search them.
That in a nutshell is intuitive behaviour for a search UI, "highlight and execute", if nothing is highlighted then search current window. Case Closed.
Yes. I want to be able to just highlight some items and search them, period.
v 2.5.0.4
Win 8.1
Xplorer2 user since at least 2005
pj
Gold Member
Gold Member
Posts: 471
Joined: 2006 Jan 26, 14:01
Location: Florida

Re: Search within selected folders

Post by pj »

Just re-installed LocaleSearch on the current work computer and -- DOESN'T WORK!!!????

OK, here's the system reset:
OS: Win 7 Pro
X2: 3.0.0.3 ULT [Unicode] 2/25/2015
LocaleSearch: v 0100, dated 5/13/2013
User command: >"%X2DIR%\Additions\LocaleSearch\LocaleSearch-v0100\LocaleSearch.exe" $A
LocaleSearch button on toolbar

Select two folders in a folder containing a few dozen folders, press the LocaleSearch toolbar button and the "Look in" field contains the parent folder name, which is the same result from pressing ctrl-F, but not the comma-separated list of the selected folders.

I'd ask if I'm crazy, but that's beside the point. Anyone confirm something changed since I last confirmed LS TOS worked using XP and x2 2.0.0.0? Did class 32770 get dismissed?

-------------------------------
PJ in FL
pj
Gold Member
Gold Member
Posts: 471
Joined: 2006 Jan 26, 14:01
Location: Florida

Re: Search within selected folders

Post by pj »

Just for grins, added the line

Code: Select all

MsgBox(0, "LocaleSearch", "Locations:" & $Locations )
and recompiled. The message box contained the comma-separated list of folders, but the Look in box still only contained the parent folder name.

--------------------
PJ in (confused) FL
Kilmatead
Platinum Member
Platinum Member
Posts: 4573
Joined: 2008 Sep 30, 06:52
Location: Dublin

Re: Search within selected folders

Post by Kilmatead »

pj wrote:Did class 32770 get dismissed?
Umm... yes, methinks the Ubiquitous Face of Evil (Dialogue Class #32770 Conflict-Bug) has arisen yet again to cause grief and strife amongst the innocent village children. :evil:

Try LocaleSearch version 0.4.0.3 and see if it pacifies the wolves (the Etruscan soothsayers say it should, and they tend to know best when it comes to studying these types of sacrificial entrails).
dunno
Gold Member
Gold Member
Posts: 506
Joined: 2007 Nov 18, 03:00
Location: Tropical Hammock

Re: Search within selected folders

Post by dunno »

Try LocaleSearch version 0.4.0.3 OK on Win7 Ult. :beer:

This is such a intuitive way of searching, the Pope should be notified to mandate it in the big book.
User avatar
ozzii
Bronze Member
Bronze Member
Posts: 124
Joined: 2005 Jun 01, 05:48

Re: Search within selected folders

Post by ozzii »

I just don't understand WHY this is still not natively in X².
"God works in mysterious ways"
Kilmatead
Platinum Member
Platinum Member
Posts: 4573
Joined: 2008 Sep 30, 06:52
Location: Dublin

Re: Search within selected folders

Post by Kilmatead »

ozzii wrote:I just don't understand WHY this is still not natively in X²
I'm largely of the opinion that it's a cultural thing - the Greeks (ancient or not) gave too much credence to the notion that the whims of the Gods themselves actually governed most of human affairs, and thus (as humans) they never developed the discipline of relying on their own intuitions because such a thing was irrelevant.

And with the decline of the warrior-culture, an under-developed intuition can result in a very learned man (the world is full of them), but not necessarily one who knows how to recognise when workflow needs to be channelled, and when it may delight in a looser rein. Intuition is a muscle, like any other, and benefits from a targeted exercise regime.

Nikos is really bad with the "forest for the trees" scope - but give him a sliver of wood and thorn in his arse, and he'll figure out a clever means of sitting down comfortably... eventually. :wink:
pj
Gold Member
Gold Member
Posts: 471
Joined: 2006 Jan 26, 14:01
Location: Florida

Re: Search within selected folders

Post by pj »

Kilmatead wrote:
pj wrote:Did class 32770 get dismissed?
Umm... yes, methinks the Ubiquitous Face of Evil (Dialogue Class #32770 Conflict-Bug) has arisen yet again to cause grief and strife amongst the innocent village children. :evil:

Try LocaleSearch version 0.4.0.3 and see if it pacifies the wolves (the Etruscan soothsayers say it should, and they tend to know best when it comes to studying these types of sacrificial entrails).
That's exactly what I expected it to be ("Ubiquitous Face of Evil"). :lol:

Thanks for the fix! :beer:
------------------------------------------
PJ in Fl
Kilmatead
Platinum Member
Platinum Member
Posts: 4573
Joined: 2008 Sep 30, 06:52
Location: Dublin

Re: Search within selected folders

Post by Kilmatead »

In case anyone is curious, the reason there are so many errant #32770 class windows running around the place (urinating on the carpet) is because when a developer designs a dialogue as a resource instead of as real Win32API code (where you can invent your own classnames), Windows automatically converts the resource into a created window, and takes care of (most of) the messy stuff the slovenly programmer otherwise would need to bother with - and it also just dimly assigns the new dialogue a generic "one size fits all" classname in the process.

This isn't just x2 - almost all programmes run on Windows use this method (the lazy bastards!) for dialogues - sometimes using it for the main window interface itself, though it's intended more for individual popup interactions rather than as a dedicated interface. What's worse, is that many programmes do not bother dismissing the windows after they're used (either on the theory that the user might summon it again, this way it's ready-made - or perhaps to keep its callback pump running for some weird [thready] reason).

The long and short of it is that if (using clever scripting stuff) you just search for a #32770 class window, it's a complete crapshoot as to whether you get the one that's actually displayed in front of you, or if you somehow snagged a background handle from another process that you totally forgot was running (such as Anti-Virus stuff, or even just a simple tray-helper).

I solved this problem by tracing-back the ancestors of each window found to see if the parent-window is the one I expect (such as x2), etc. Nothing very exciting, but tedious, and it seems to solve the problem.

In this case, I had just forgotten to update the script. Sorry about that. :shrug:

Curiously, by making me jump through all these ridiculous hoops to create work-arounds for his bloody design-shortfalls, Nikos is weirdly contributing to my education in matters which ordinarily would not surface until much later. Whether this is a good thing or not (or just scars me for life), one is left to ponder. :D
pj
Gold Member
Gold Member
Posts: 471
Joined: 2006 Jan 26, 14:01
Location: Florida

Re: Search within selected folders

Post by pj »

Kilmatead wrote:
pj wrote:Did class 32770 get dismissed?
Umm... yes, methinks the Ubiquitous Face of Evil (Dialogue Class #32770 Conflict-Bug) has arisen yet again to cause grief and strife amongst the innocent village children. :evil:

Try LocaleSearch version 0.4.0.3 and see if it pacifies the wolves (the Etruscan soothsayers say it should, and they tend to know best when it comes to studying these types of sacrificial entrails).
The limitation of the command line length passed to an AutoIt script limits the number of folders passed at one time. In one instance where I selected a modest 27 folders, only 14 made it to the search dialog Look In control.

I tweaked the code to expect the 1st parameter as the parent of the selected folders, then only the names of the selected items are passed for the remainder of the command line and the full path is expanded within the code.

The user command has to change to:

Code: Select all

>"%X2DIR%\LocaleSearch.exe" $P $S
This increased the maximum number of folders that could be passed somewhat. The actual number will probably depend on the length of the base/parent path string, and the Look In control's maximum character number limit. For now, I can get all 27 (plus a few more) passed with no issues.

The modified code is below:

Code: Select all

#NoTrayIcon
#Region ;**** Directives created by AutoIt3Wrapper_GUI ****
#AutoIt3Wrapper_Icon=LocaleSearch.ico
#AutoIt3Wrapper_Compile_Both=y
#AutoIt3Wrapper_UseX64=y
#AutoIt3Wrapper_Res_Description=x2 Search in Selected Locations
#AutoIt3Wrapper_Res_Fileversion=0.4.0.3
#AutoIt3Wrapper_AU3Check_Parameters=-d -w 1 -w 2 -w 3 -w 4 -w 5 -w 6
#AutoIt3Wrapper_Run_After=move "%out%" ..
#AutoIt3Wrapper_Run_After=move "%outx64%" ..
#AutoIt3Wrapper_Run_After=del "%scriptdir%\%scriptfile%_stripped.au3"
#Au3Stripper_Parameters=/SO /RM
#EndRegion ;**** Directives created by AutoIt3Wrapper_GUI ****
; Changelog for 0.5.0.0

; Increased number of parameters by changing commmand line parameters to $P $S  ({Path} {All selected filenames}) and combining the parameters internally.
; This is due to the limitations of the CmdLine input string length of 2079 or so...
; Doesn't fix the limitation, but applies a bandaid to get higher number of folders passed at one time.

; Fixed: The world should now be safe from the tyranny of classname #32770

; Changelog for 0.4.0.2

; Added: Names of selected folders are automatically listed in the title of the Scrap Window itself

; Changelog for 0.4.0.1

; Added: Scrap-Pane compatibility for miniscraps and containers
; Added: Number of selected locations is displayed in the titlebar of the options-menu window (invalid [non-folder] selections are not counted)

; Release 0.1.0.0


#include <Array.au3>

#include <Process.au3>
#include <WinAPIEx.au3>
#include <WinAPIShPath.au3>
#include <WindowsConstants.au3>

Opt("WinWaitDelay", 0)

Global $Scrap = False

Global $hWin = WinActivate("[CLASS:ATL:ExplorerFrame]", "")
If Not $hWin Then
	$hWin = WinActivate("[CLASS:ATL:ScrapFrame]", "")
	$Scrap = True
Else
	If _GetActivePane($hWin) = "ATL:BrowserListView1" Then $Scrap = True
EndIf

If $hWin Then
	Global Const $LOOK_IN = 1014
	Global Const $NAMED = 1015
	Global Const $FIND_FILES_OR_FOLDERS = 32885
	Global Const $CLEAR = 1068

	Global $Locations = "", $Labels = "", $ValidItems = 0, $BasePath = "", $FullPath = ""

	; Build each entry using the 1st cmdline parameter as the base path, and each additional item is the local file/folder name
	$BasePath = $CmdLine[1] & "\"

	For $i = 2 To $CmdLine[0]
		$FullPath = $BasePath & $CmdLine[$i]
		If _WinAPI_PathIsDirectory($FullPath) Then
			$Locations &= StringReplace($FullPath, ",", ",,") & ", "
			$Labels &= _WinAPI_PathFindFileName($FullPath) & "; "
			$ValidItems += 1
		EndIf
	Next

	If $Scrap And $ValidItems Then
		$hWin = _GetWinFromPID(Run(_Quoted(EnvGet("X2DIR") & _ProcessGetName(WinGetProcess($hWin))) & " " & _Quoted("/F:1") & " " & _Quoted("/L:::{20D04FE0-3AEA-1069-A2D8-08002B30309D}")))
	Else
		WinActivate($hWin)
		_WinAPI_PostMessage($hWin, $WM_COMMAND, $FIND_FILES_OR_FOLDERS, 0)
	EndIf

	$hWin = _WinWaitChild_32770()
	If $hWin Then
		;Sleep(100)
		If $Labels = "" Then $Labels = _WinAPI_PathFindFileName(StringReplace(ControlGetText($hWin, "", $LOOK_IN), ",,", ",")) & "; "
		$Labels = StringTrimRight($Labels, 2)
		WinSetTitle("[CLASS:ATL:ScrapFrame]", "", "Search of: " & $Labels)
		_SendMessage($hWin, $WM_COMMAND, $CLEAR)
		ControlSetText($hWin, "", $NAMED, "*?") ; Override default "last used" filter for a more generic one and highlight it
		ControlFocus($hWin, "", $NAMED)
		ControlSetText($hWin, "", "[CLASS:Edit; INSTANCE:5]", "") ; Clear the "Predefined" bar as well so all fields are empty

		If $ValidItems Then
			WinSetTitle($hWin, "", WinGetTitle($hWin, "") & " (Searching " & $ValidItems & " Location" & (($ValidItems = 1) ? "" : "s") & ")")
			ControlSetText($hWin, "", $LOOK_IN, StringTrimRight($Locations, 2)) ; Trim trailing "comma+space" characters
		Else
			WinSetTitle($hWin, "", WinGetTitle($hWin, "") & " (Searching Base Folder)")
			$Labels = ControlGetText($hWin, "", $LOOK_IN)
		EndIf

		If WinWaitNotActive($hWin) Then
			Sleep(100)
			WinSetTitle("[CLASS:ATL:ScrapFrame]", "", "Search of: " & $Labels)
		EndIf
	Else
		MsgBox(16, "LocaleSearch", "x2 Search Instance Not Found")
		Exit
	EndIf
Else
	MsgBox(16, "LocaleSearch", "x2 Window Instance Inactive or Not Found")
EndIf

Func _GetActivePane($hWin)
	Local Const $ADDRESSBAR = 1001
	Local $sContents = ControlGetText($hWin, "", $ADDRESSBAR)

	ControlSetText($hWin, "", $ADDRESSBAR, "")
	ControlFocus($hWin, "", $ADDRESSBAR)
	ControlSend($hWin, "", $ADDRESSBAR, "{ENTER}")
	ControlSetText($hWin, "", $ADDRESSBAR, $sContents)

	Return ControlGetFocus($hWin) ; MiniScrap = ATL:BrowserListView1
EndFunc

Func _Quoted($Str)
	Return Chr(0x22) & $Str & Chr(0x22)
EndFunc

Func _WinWaitChild_32770($iWait = 3) ; More robust version of WinWaitActive("[CLASS:#32770]", "", 3) - guarantees not to match children from foreign processes
	Local $Timeout = TimerInit()
	If $iWait < 1000 Then $iWait *= 1000

	While TimerDiff($Timeout) < $iWait
		Local $aList = WinList("[CLASS:#32770]")

		For $i = 1 To $aList[0][0]
			If BitAND(WinGetState($aList[$i][1]), 2) = 2 And _
					StringRegExp(_WinAPI_GetClassName(_WinAPI_GetAncestor($aList[$i][1], $GA_ROOTOWNER)), "[REGEXPCLASS:ATL:(Explorer)|(Scrap)Frame]") Then Return $aList[$i][1]
		Next

		Sleep(10)
	WEnd

	Return 0
EndFunc

Func _GetWinFromPID($PID)
	While True
	Local $aList = processList()
	For $i = 1 To $aList[0][0]
		If StringLeft($aList[$i][0], 5) <> "scrap" Then $aList[$i][0] = ""
		;ConsoleWrite($PID & " = " & WinGetProcess($aList[$i][1]) & @lf)
		If $aList[$i][1] = $PID Then Return wingethandle($aList[$i][0])
	Next
WEnd
	Return 0
EndFunc
-----------------------
PJ in (tweaking not twerking) FL
Kilmatead
Platinum Member
Platinum Member
Posts: 4573
Joined: 2008 Sep 30, 06:52
Location: Dublin

Re: Search within selected folders

Post by Kilmatead »

Except it wreaks the ability to search folderpaths gleaned from scrap-containers (such as the results of previous searches, or collected items in the miniscrap). I chose the widest functionality over the largest number of immediate paths.

Another solution (which would only be limited by the size of the window buffer, not any command-line stuff) would be to make LocaleSearch compatible with the "$>" token, so the full paths are shunted into the temp file, then parsed by the script into 8.3 path-format (to trim their overall lengths), and then collated into the search.

I wonder what the max buffersize is for the "Look In" control...

{Edit] ... a quick test shows that it seems to accept "at least" 4096 contiguous characters (I got tired of typing nonsense paths at that point), which I should think would be more than enough. So, I'll just switch it over to $> rather than $A which is easy enough. And maybe short-form paths "just for fun". :shrug: This way all functionality is preserved without sacrificing one for t'other.
Kilmatead
Platinum Member
Platinum Member
Posts: 4573
Joined: 2008 Sep 30, 06:52
Location: Dublin

Re: Search within selected folders

Post by Kilmatead »

And so LocaleSearch 0.4.0.4 is born. :roll:

The user-command format must be: LocaleSearch.exe $>

I forewent the conversion to 8.3 paths for simplicity (for now), as I tried a test of 138 paths at 5,234 characters, and (weirdly) though the text was not actually "displayed" in the Look In field, it registered and worked fine, so that's that. The text will still normally be displayed in the field (apparently for shorter lengths, though, whatever that may amount to). :shrug:

I also eschewed your audacious and OTT version increment and kept it respectably small. :wink:

Anyway, full functionality is preserved without CLI truncation issues. :D
pj
Gold Member
Gold Member
Posts: 471
Joined: 2006 Jan 26, 14:01
Location: Florida

Re: Search within selected folders

Post by pj »

NICE! Works like a champ!

I was thinking about the list thing, too, but didn't see the parameter listed in the help screen and didn't have time to research it. Not surprising I guess...

----------------------------
PJ in (ONE RAIN CLOUD THIS WEEK AND IT HAS TO COME AT LAUNCH TIME --- GEEZE!!!!) FL
Kilmatead
Platinum Member
Platinum Member
Posts: 4573
Joined: 2008 Sep 30, 06:52
Location: Dublin

Re: Search within selected folders

Post by Kilmatead »

pj wrote:...but didn't see the parameter listed in the help screen
Yeah, Nikos refuses to document it because he can't conceive of something he didn't think of as actually being a good idea. That hubris shall be my vector-of-revenge when the time is nigh and the moon is high. :wink:
pj
Gold Member
Gold Member
Posts: 471
Joined: 2006 Jan 26, 14:01
Location: Florida

Re: Search within selected folders

Post by pj »

There is an apparent dismissal of all these extensions you and others have created that enhance x2's productivity, but, unless you're in-the-know or one of the obsessive insiders like us, they're hidden for the most part. Even the implementation of the "useful" group of topics was half-hearted, and no changes have been made to either the forums or the web site since - excepting adoption of an awful color scheme.

The lack of a decent Extensions page on his web site shows more of his "doesn't get it" attitude. If all people see is Yet Another File Manager, there isn't anything to distinguish x2 from the crowd, and it will continue to get trampled from a sales point of view.

It's all about PROMOTION and MARKETING, which is sadly lacking. I want Nikos to be wildly successful so x2 enhancements, bug fixes and growth can be funded and to ready meet my needs with more than 200x level programming. Fortunately at the moment I'm still a 200x kind-of-guy, so for now that's all I need.

I'm not familiar with the TC plug-ins, but that may be the "next great thing" to help kick x2 to the next level. At least you got some kudos for that effort!
Post Reply