(I searched the forum, but did not find a topic similar to this)
In B2, when dual trees are displayed and a successful search concludes, "feed to listbox" works properly, but the folder highlighted in the associated tree does not change and is obviously incorrect for the search results now resident in the file list. To redisplay the former file list, currently one clicks the highlighted folder in the associated tree.
That works OK, but my suggestion is:
... after "feed to listbox", add (or update) a persistent folder viewable in both trees called "Search Results" and move the active tree's focus to that folder.
One would then issue cm_GotoPreviousDir to return to the folder active prior to the search.
An extension of this request would be:
Place a flag in the search dialog to "save results to Search Results folder".
If the "save results" flag is set, "feed to listbox" would post the search results list to the "Search Results" folder as a subfolder, identified/named by either date/time or search criteria or saved search name. Then, one could (at any time thereafter) use the tree to navigate to a former search result, causing a redisplay (in the file list) of the results, or a re-execution of the search (depending on implementation).
The search results file lists would be stored in INI-like files placed in a user-defined location. The content of the search results file would be a list of the files found during the most recent search, plus a definition of the search, and a flag to indicate whether to re-execute the search or just display the former result in the file list.
An issue: how/whether to save a result if very large numbers of files are found.
[REQ] Persistent Search Results Folder in Tree
Moderators: white, Hacker, petermad, Stefan2
[REQ] Persistent Search Results Folder in Tree
Last edited by JohnFredC on 2006-12-05, 16:02 UTC, edited 1 time in total.
Licensed, Mouse-Centric, moving (slowly) toward Touch-centric
My request was specifically for saving searches in the tree... one would then select the search "subfolder" from the tree and have the "found" files appear in the file list.
It turns out after a little research that using a ShellObject editor to create a "TC Searches" shell object AND redirecting the Searches section to an INI stored in that folder may be a start in the right direction.
Lots of other pieces to this, though, and I think AHK might help.
Pieces possibly needed:
1. WFX Plugin to treat the redirected INI file as a folder and to display the search definitions in the file list as subfolders (of the "TC Searches" shell folder)
2. AHK Script to execute a search "file" selected from the decoded Search file list, then "copy to list box", "select all", and pack to LST file stored in "TC Searches" shell folder. Then the LST plugin could get the filenames out of the LST file and into the TC file list as the contents of the highlighted search "subfolder".
... and some more UI/data stuff, including flags to always vs prompt to re-execute the search.
I probably won't go to all this trouble (busy here) but it seems technically feasible to do, given thought.
It turns out after a little research that using a ShellObject editor to create a "TC Searches" shell object AND redirecting the Searches section to an INI stored in that folder may be a start in the right direction.
Lots of other pieces to this, though, and I think AHK might help.
Pieces possibly needed:
1. WFX Plugin to treat the redirected INI file as a folder and to display the search definitions in the file list as subfolders (of the "TC Searches" shell folder)
2. AHK Script to execute a search "file" selected from the decoded Search file list, then "copy to list box", "select all", and pack to LST file stored in "TC Searches" shell folder. Then the LST plugin could get the filenames out of the LST file and into the TC file list as the contents of the highlighted search "subfolder".
... and some more UI/data stuff, including flags to always vs prompt to re-execute the search.
I probably won't go to all this trouble (busy here) but it seems technically feasible to do, given thought.
Licensed, Mouse-Centric, moving (slowly) toward Touch-centric
Hi Lefteous...
My suggestions rarely have very high priority with Mr. Ghisler or others who post here
, so after giving it some thought, an approach "within (nearly) available resources" occurred to me.
Naturally, I would extremely prefer that the requested functionality be native to TC.
TC probably needs a tree-plugin interface (wtx?) also.
My suggestions rarely have very high priority with Mr. Ghisler or others who post here
, so after giving it some thought, an approach "within (nearly) available resources" occurred to me.Naturally, I would extremely prefer that the requested functionality be native to TC.
TC probably needs a tree-plugin interface (wtx?) also.
Licensed, Mouse-Centric, moving (slowly) toward Touch-centric
Oh well - there are so many suggestions - don't take it personally. This only thing that irritated me is this "mouse-centric". I have never seen a designer working with Photoshop or Flash without using both keyboard and mouse or someone playing Quake without using both keyboard and mouse. Both devices are useful depending on the context of use.My suggestions rarely have very high priority with Mr. Ghisler or others who post here
Me too search result handling in TC is currently quite limited.Naturally, I would extremely prefer that the requested functionality be native to TC.
I don't think this is really necessary. The tree is just one way to access resources. Persistent search results should be available anywhere. My idea to integrate persistent search results would be to add an "Search results" entry as a new root in the tree.TC probably needs a tree-plugin interface (wtx?) also.
During the alpha test we discussed having multiple roots in the tree. The first is the shell namespace. The others are TC specific: FTP, filesystem plug-ins and search results could be another root. I made this illustration a while ago:
http://www.lefteous.de/tc/images/misc/tree_roots.png
I am curious: what were the arguments against multiple roots?
[OT]
It seems wrong to me to limit progress in the TC UI because of the difficulty/impossibility in designing the keyboard interface to such new features. For instance, folder trees have come to TC quite late (in comparison to the competition), no doubt in part because of the difficulty of integrating them into TCs keyboard interface.
At some point, perhaps, it may need to be said, "If you don't use the mouse, you can't do that!"
I have a tablet PC budgeted for 2007. Will be interesting to see how well TC works in that context.
Cheers!
[/OT]
[OT]
I constantly have one hand on the mouse and the other on the keyboard for shift/ctrl/alt, etc. So, of course I do not advocate limiting the keyboard interface to TC. That would be absolutely crazy. TC just should be more up-to-date for mouse users. There are a LOT of good mouse UI ideas out there, many applicable to a commander-style file manager such as TC.Both devices are useful depending on the context of use.
It seems wrong to me to limit progress in the TC UI because of the difficulty/impossibility in designing the keyboard interface to such new features. For instance, folder trees have come to TC quite late (in comparison to the competition), no doubt in part because of the difficulty of integrating them into TCs keyboard interface.
At some point, perhaps, it may need to be said, "If you don't use the mouse, you can't do that!"
I have a tablet PC budgeted for 2007. Will be interesting to see how well TC works in that context.
Cheers!
[/OT]
Licensed, Mouse-Centric, moving (slowly) toward Touch-centric