Yes. I want to be able to just highlight some items and search them, period.dunno wrote:That in a nutshell is intuitive behaviour for a search UI, "highlight and execute", if nothing is highlighted then search current window. Case Closed.otlaolap wrote: what do I want? Highlight some Items and search them.
Search within selected folders
Moderators: fgagnon, nikos, Site Mods
Re: Search within selected folders
v 2.5.0.4
Win 8.1
Xplorer2 user since at least 2005
Win 8.1
Xplorer2 user since at least 2005
Re: Search within selected folders
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
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
Re: Search within selected folders
Just for grins, added the line
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
Code: Select all
MsgBox(0, "LocaleSearch", "Locations:" & $Locations )
--------------------
PJ in (confused) FL
Re: Search within selected folders
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.pj wrote:Did class 32770 get dismissed?
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).
Re: Search within selected folders
Try LocaleSearch version 0.4.0.3 OK on Win7 Ult.
This is such a intuitive way of searching, the Pope should be notified to mandate it in the big book.
This is such a intuitive way of searching, the Pope should be notified to mandate it in the big book.
Re: Search within selected folders
I just don't understand WHY this is still not natively in X².
"God works in mysterious ways"
"God works in mysterious ways"
Re: Search within selected folders
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.ozzii wrote:I just don't understand WHY this is still not natively in X²
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.
Re: Search within selected folders
That's exactly what I expected it to be ("Ubiquitous Face of Evil").Kilmatead wrote: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.pj wrote:Did class 32770 get dismissed?
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).
Thanks for the fix!
------------------------------------------
PJ in Fl
Re: Search within selected folders
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.
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.
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.
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.
Re: Search within selected folders
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.Kilmatead wrote: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.pj wrote:Did class 32770 get dismissed?
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).
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
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
Re: Search within selected folders
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". This way all functionality is preserved without sacrificing one for t'other.
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". This way all functionality is preserved without sacrificing one for t'other.
Re: Search within selected folders
And so LocaleSearch 0.4.0.4 is born.
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).
I also eschewed your audacious and OTT version increment and kept it respectably small.
Anyway, full functionality is preserved without CLI truncation issues.
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).
I also eschewed your audacious and OTT version increment and kept it respectably small.
Anyway, full functionality is preserved without CLI truncation issues.
Re: Search within selected folders
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
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
Re: Search within selected folders
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.pj wrote:...but didn't see the parameter listed in the help screen
Re: Search within selected folders
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!
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!