Clearing File Filter Field Upon Directory Change

Is there a way to clear the file filter field upon changing a directory? If not I could add a request in the suggestions forum.

I am not sure if this holds true for others, but 90% of the time I manually have to clear the file filter field upon changing a directory. It would be much easier to check a box to hold the file filter 10% of the time.

Thanks!

What sort of things are you using the filter for that only apply to one directory? If you're always using the same filters for a few specific directories then you could save the filters in Folder Formats for those directories so they'll automatically be applied when you enter the directories and removed when you leave them.

You can also make a Clear Filters button or hotkey, if that's useful:<?xml version="1.0"?> <button display="both" effect="gray" label_pos="right"> <label>Clear Filters</label> <icon1>139</icon1> <function type="normal"> <instruction>Set SHOWFILTERFILENAME=""</instruction> <instruction>Set HIDEFILTERFILENAME=""</instruction> <instruction>Set SHOWFILTERFOLDERS=""</instruction> <instruction>Set HIDEFILTERFOLDERS=""</instruction> <instruction>Select NOPATTERN SHOWHIDDEN</instruction> </function> </button>

I think I know where Briana's coming from.

For example, when I work with graphics files (wallpapers, web buttons, etc), I work with about 5 different file formats and often dozens of image files per project. I usually have a different format of each file at different stages of the graphic development. I store the files in a folder by project or task. I might want to filter files so just the files I need to inventory or review are listed: just the .jpgs, just the .gifs, or just the .pngs, etc. Sometimes, I want to see all the different formats of a particular graphic, so I filter for the filename, not the extension.

I try use the toolbar filter fields to to take a huge file list down to just what I'm looking for at that moment. It's much quicker than searching for files by scrolling that infernal mouse, and its quicker than having to create and run a Find to get them to a collection.

The user is already in the folder, and remembers that a name started with XYZ-somethingsomething and it was a .jpg file. So just type "XYZ*.jpg" in the file filter box and a 1000-file folder listing shrinks down to just what is needed for the moment. Edit that image and then I change the filter to the next file ABCsomethingsomething.gif, in the same folder. Same thing, type ABC*.gif, and bam, the list gets short very quickly.

This is more of a dynamic filter usage, not the more static usage of filtering all system folders from view (thumbs.db, desktop.ini, etc).

[quote]I try use the toolbar filter fields to to take a huge file list down to just what I'm looking for at that moment. It's mush quicker than searching for files by scrolling that infernal mouse, and its quicker than having to create and run a Find to get them to a collection.

The user is already in the folder, and remembers that a name started with XYZ-somethingsomething and it was a .jpg file. So just type "XYZ*.jpg" in the file filter box and a 1000-file folder listing shrinks down to just what is needed for the moment. Edit that image and then I change the filter to the next file ABCsomethingsomething.gif, in the same folder. Same thing, type ABC*.gif, and bam, the list gets short very quickly.[/quote]

This is exactly how I usually use filters. I usually have a ton of files in a directory and want to quickly find the file I am looking for. Thus, when I change directories I no longer wish to keep the filter.

Please let me know if you want me to elaborate more.

Thanks!

Opus flexibility to the rescue. :slight_smile:

Select Settings > File Types... from the default menus, then double-click the All folders type near the top of the list.

On the Events tab there should be a dblclk (double-click) event which runs go. Edit that and make it run this instead:

Set SHOWFILTERFILENAME="" Set HIDEFILTERFILENAME="" Set SHOWFILTERFOLDERS="" Set HIDEFILTERFOLDERS="" Select NOPATTERN SHOWHIDDEN go
Now when you double-click folders the filter will be cleared before they are entered.

Of course, you'll need to make similar changes to other navigation methods, e.g. change the Backspace hotkey (via the Customize dialog), and so on.

I don't think you'll be able to clear the filter when clicking on generated list of DriveButtons but you could always manually make buttons which clear the filter and go to each drive if you need them.

You won't be able to change what the File Display Border's parent button does, but you can change the parent button on your toolbar.

What about the "GO UP" button in the dual-pane lister? I don't see a way to customize the tiny back and up buttons.

Thanks for the help!

Unfortunately you can't change them. That's what I meant by:

It sounds to me that Opus users could benefit from two layers of Folder Filters. The first layer would be more static, the filter set in Folder Formats, to filter out system files, and what not. The second layer would be more dynamic, that the user enters when browsing a folder for the particular items at that moment.

The filter effectually applied to the folder would be an amalgamate of the two layers, with the options in the dynamic layer taking precedence over options in the static layer.

The static layer would remain when the user navigates from folder to folder (pulled from Folder Formats). The dynamic layer would always get reset from folder to folder (pulled from the Filter Fields).

This would operate similar to the %DIRCMD% environmental variable in the Windows Command Prompt. The user can configure %DIRCMD% to store DIR command parameters that govern the DIR output format the user would most likely desire all the time (the static portion). Additionally, when the user types a DIR command, anywhere in Windows, the user may type explicit command parameters to modify the DIR command's behavior for the specific task at hand.

I feel a feature request coming on.

Am I missing anything in the ideas here?

Is there any way to have the file filter field act exactly like the "select files" advanced selection. I just changed tabs and waited for 30 seconds for the files to appear realizing that the file filter field needs to be cleared when I change tabs also! The way I use it is just to find files and folders quickly when I am browsing large directories. It would be very nice if there was an option to clear when changing directories or tabs.

BTW, should I move this to the request forum?

Thanks!

[quote="kenalcock"]It sounds to me that Opus users could benefit from two layers of Folder Filters...

...Am I missing anything in the ideas here?[/quote]
Well, the existing 'static' filters tied to the folder options/format system and the recently added file filter 'field' are already two separate layers sort of - are they not? So that differentiation is already here... I'd say to just ask GPSoft to extend the functionality for the file filter field to include a 'cwd' or 'current' or 'resetondirchange' or some other such argument that you could either select from the field drop down list or bind to the actual field as an argument like we currently have for any of the other filter field options like realtime/partial/etc etc.

No?

This is how I was envisioning such a layered approach between Static and Dynamic filters:

These are the filter fields on the Folder Options/Folder Formats dialog:

[ul][li] Show Filter[ul][li] Files[/li]
[li] Folders[/li]
[li] Attributes[/li][/ul][/li][li] Hide Filter[ul][li] Files[/li]
[li] Folders[/li]
[li] Attributes[/li][/ul][/li][/ul]These fields would become the Static Filter Layer. That is, the user could still configure these filters via already existing Raw commands, Folder Formats Filter dialog, Default Formats Filter dialog, Content Type Formats Filter dialog, etc. However, these filters would remain in effect when the user navigates from folder to folder.

The new Filter field that you speak of would set filters in addition to the ones above, with options to: logically AND the two filter layers together, or to have the dynamic filter override the Static Layer. However, when the user lists a different folder, this filter layer is completely forgotten.

I would further suggest that this filter layer utilize the Filter subsystem (the complete and more robust filter dialog that can be used for Copy, Move, Delete, Find, and Synchronize).

This is what is significantly from the above suggested behavior, to the way Opus behaves today:

TODAY
The user changes the filter in the filter field and it always overrides the filter in the Folder Options/Folder Formats dialog fields I listed above.

SUGGESTED
The user has the option of combining the filter in the Filter Field with that of the Folder Options/Folder Formats dialog fields I listed above, without overwriting them. That is, those filters remain in effect. There would still be an option for the Filter Field to override the other fields, but it would no longer be the default option.

RATIONALE
With the suggested changes, the user can set static filters to hide files such as Thumbs.db, desktop.ini, et cetera (without hiding all system and/or hidden files) that reaming hidden all the time. And allows the Filter Field to be used to trim a long file list to a short one with just the files the user wishes to see at that moment.

Ok, so it seems that a few other 'options' to the filter field would do what you're suggesting. The initial filter layer is already 'static' for all intents and purposes, so you've now added a good idea to extend functionality of the filter field to accomodate some of the weak areas of how the filter field integrates into the 'static' filter functionality (i.e. 'Clear Filters' menu option from the file filter field actually whacks the folder options/formats based 'static' filters)...

Seems like simply adding express options to the file filter field to allow users to specifically 'preserve' (probably desired by most to be the default) and 'clear' (in many cases probably NOT desired by most as the default) external filters (from the options/formats show/hide system) as well as an option to 'clear dynamic filters on folder change' would do all of what you're suggesting.

Back to the 'clearing of dynamic filters on folder change' idea:
Personally, I would advocate NOT making the 'dynamic' filter reset on directory change the basic behaviour without an 'option' to control it... there are 'levels' of dynamic behaviour after all. For instance, some people might want to switch between several related project folders and have the 'dynamic' filter remain in effect... I very often do this sort of thing to switch between various project folders and clean up temp files or debug output before doing a new test build; and brian even guestimated he still might have 10% of his work 'keep' the filter in place between folders...

As an aside... regardless of 'default' functionality of the 'dynamic' filter field, it might also be nice to be able to reapply the 'last used filter' as a raw command similar to how the rename dialog and function lets you run the the 'last' rename pattern/preset again. You can naturally re-select any filter from the filter field drop down, but I'd rather have my hand on a hotkey as I cycle through folders to reapply the filter.

Another aside... there was a comment that even when switching tabs - brian needed to clear the filter? I don't see this behavior - even if I add the file filter field on a 'global' toolbar rather than a 'local' one...

I agree the current Folder Options/Folder Formats Filter fields would require no changes. The bulk of the changes is changing how the Filter Field is: applied, remembered, or reused. The Filter Field in essence becomes a second filter layer, one that is more dynamic.

Not exactly. The static filter Layer should always be preserved. This is the very reason for having two layers instead of one--so the dynamic layer never overwrites the static layer. If you overwrite the static layer with the dynamic it is no longer available when the user changes folders. (This is exactly what happens today if you visualize the current Filter Field as a dynamic layer.)

Rather than the Filter Field overwriting the static filter, the Filter Field should have an option like this:

Use Folder Options Filter :[ol] [li] ON - This results in the static and dynamic filter layers used together in a logical AND.

For example, the static filter is configured to always hide desktop.ini files. But for the current operation the user configures the dynamic filter field to display all *.ini files. With the static and dynamic layers combined using a logical AND, all .ini files except desktop.ini will be displayed.
[/li]
[li] OFF - Results in the dynamic filter layer used in place of the static layer. The static filter is not overwritten, it simply isn't used; this way when the user switches to another folder after the current operation is concluded, the static filter is is reapplied to the new folder.

With Use Folder Options Filter OFF, and the same static and dynamic filters as above, the current operation would display all .ini files including desktop.ini.[/li][/ol][quote] Back to the 'clearing of dynamic filters on folder change' idea:
Personally, I would advocate NOT making the 'dynamic' filter reset on directory change the basic behaviour without an 'option' to control it...[/quote]
I agree. The dynamic filter layer should have a lock the user could set ON or OFF as desired. If you observe many of the current Filter Field options (accessible by right-clicking the icon inside of the field), how the option is set is how it will be set the next time a new lister is opened. For example, enable the Partial Match option, close the lister, then open a new lister. Partial Match will still be enabled. The Filter Field should have a Dynamic Filter Lock option that works in a similar manner.

This is isn't a bad idea, but I don't know how feasible it would be to code.

I do not see this behavior either. In addition to what you tried, I tried to open a folder set a filter to hide *.txt files in the Filter Field and then opened several tabs based upon that listing. In each new tab, the Filter Filed was reset and the Folder Options/Folder Formats filters were used. Ironically that is exactly how I'd like the filter to work when I'm browsing vertically up and down a folder structure in a single lister.

I wonder if there was an argument set for the Filter Field that caused the behavior?

Hello Ken and Steje,
Hello Steje and Ken,

I overlooked this thread in the beginning, but it is becoming relativistic.

Here is what I have trouble with.
@Ken

What if AND is false ?

@Steje

My take on this almost the same, but reversed.
Add these express options to the static layer instead.

That's my two cents worth.

:opusicon: Porcupine

Interesting discussion guys.

What I'm currently thinking of for the next version is along these lines - a simple "view filter" which is applied to the current view only, and is cleared automatically whenever you change folders. This filter is effectively a "show" filter - it lets you use a wildcard pattern to specify which files you want to show, and is applied on top of any filters set by Folder Options.

There is also an option to auto-populate the drop-down filter control with a list of file extensions from the current Lister. So if, for example, you want to quickly isolate all the .jpg files in the current view, simply drop down the filter list and select "*.jpg".

If any branch of a logical AND is False the statement is always False.

But your point has given me cause to think a bit more. I agree the user need to have the option be a choice of three, instead of a choice of two. The user should select one of these three options:[ol][li] Dynamic filter is used in place of the static filter (default out-of-the box).[/li]
[li] AND the dynamic filter to the static filter.[/li]
[li] OR the dynamic filter to the static filter.[/li][/ol]

The AND and the OR option are no different than using a subclause in the Advanced Selection Filter with either an AND logic branch or an OR logic branch. If the logic branches themselves do not play nice together, that is the user's responsibility since the user created both branches. But with regard to how each of the two layers is used (or if it they are used), this is all the options Opus should provide. If the Filter subsystem (in Advanced Selection) does not handle the other logical operators, then there is no reason to add them here (XOR NAND, etc).

Remember than if these suggestions were implemented, the user would set things in the static filter that they would want applied more globally at the Folder Format level (Default Formats, Content Type Formats, or Folder Formats). The Filter Field

Today there is only one level of filters, thus the what I am referring to as the static filter, is currently the only filter.

[quote="jon"]Interesting discussion guys.

What I'm currently thinking of for the next version is along these lines - a simple "view filter" which is applied to the current view only, and is cleared automatically whenever you change folders. This filter is effectively a "show" filter - it lets you use a wildcard pattern to specify which files you want to show, and is applied on top of any filters set by Folder Options.

There is also an option to auto-populate the drop-down filter control with a list of file extensions from the current Lister. So if, for example, you want to quickly isolate all the .jpg files in the current view, simply drop down the filter list and select "*.jpg".[/quote]

Jon, anyway to add the Filter Subsystem in there? (That is the powerful one used in Find, Synchronize, Advanced Selection, et cetera.)

I would suggest something like the Simple versus Advanced Find dialog.

Except it would be like a Simple versus Advanced Filter.

Then if people are looking for image files of a certain type in a certain size (which just came up in a thread today), rather than sorting the list, to find things meeting criteria, the list could be filtered to show only those that meet the criteria.

@Jon. IMO your idea (as typed above) hit the nail on the head of what I was talking about to begin with. I think the confusion comes in when people try to envision how the new filter would work with (or perhaps against) the current one today.