Where are the types for "find by type" defined?

[j_c_hallgren]

Ok, so I'm a bit behind lately on installing new vers...anyway...the new-ish "Find by types" has a list of various groups of file types, such as media...but where are these defined (as to which are in a given group)? And is there a way to change these or add new ones (both a specific type to a group or a group itself)?

[admin]

Ok, so I'm a bit behind lately on installing new vers...anyway...the new-ish "Find by types" has a list of various groups of file types, such as media...but where are these defined (as to which are in a given group)? And is there a way to change these or add new ones (both a specific type to a group or a group itself)?

They are internally defined, not via INI. But you can add to the lists via INI tweaks:

Code: Select all

    * Type Filter: Changed the format of the tweak to add custom 
      extensions. Now the extension lists should be dot-separated 
      (before, they were comma-separated):
        AudioPreviewCustomExtensions=bim.bam.bum
        VideoPreviewCustomExtensions=
        VectorPreviewCustomExtensions=
        ArchivePreviewCustomExtensions=
        ExePreviewCustomExtensions=

You cannot remove anything from the internal lists, though. This might be changed later if there's demand.

To view the lists put the cursor into the Type Filter field and press F1.

[j_c_hallgren]

They are internally defined, not via INI. But you can add to the lists via INI tweaks:
You cannot remove anything from the internal lists, though. This might be changed later if there's demand.

To view the lists put the cursor into the Type Filter field and press F1.

Ah, ok...I'd seen that tweak in beta but didn't fully catch context...so now that I can view lists, I see a couple of things that seem a bit unusual to me...like "*.hlp" in "Executable"?

Also, it's a bit difficult to view the multiple lists, as you have to select each one and then F1...not THAT bad, but could be easier.

[admin]

They are internally defined, not via INI. But you can add to the lists via INI tweaks:
You cannot remove anything from the internal lists, though. This might be changed later if there's demand.

To view the lists put the cursor into the Type Filter field and press F1.

Ah, ok...I'd seen that tweak in beta but didn't fully catch context...so now that I can view lists, I see a couple of things that seem a bit unusual to me...like "*.hlp" in "Executable"?

Also, it's a bit difficult to view the multiple lists, as you have to select each one and then F1...not THAT bad, but could be easier.

"*.hlp" in "Executable" ... yes right, hmmm, why did I do that? ... Any other unusual things?

[j_c_hallgren]

"*.hlp" in "Executable" ... yes right, hmmm, why did I do that? ... Any other unusual things?

Well, similar would be "*.chm" in same maybe?

And I personally don't view 'url' and 'lnk' as executable...url is a 'web type' for sure but lnk is what I might call 'system' files maybe? Same with 'reg' as it can't do anything by itself and is more of a data file.

Others here likely may have different opinions on what extensions belong to what groups...that's why ability to tweak (at least) or customize becomes important

And yes, it's a great addition but only when you know what results will be.

[admin]

"*.hlp" in "Executable" ... yes right, hmmm, why did I do that? ... Any other unusual things?

Well, similar would be "*.chm" in same maybe?

And I personally don't view 'url' and 'lnk' as executable...url is a 'web type' for sure but lnk is what I might call 'system' files maybe? Same with 'reg' as it can't do anything by itself and is more of a data file.

CHM is compiled HTML so it is executable I think.
LNK can be anything, and often points to executables...

URL and REG, agreed.

[admin]

PS: REG can be seen as a script, and under "Exectuables" I also subsume all sorts of scripts.

So REG can stay, but HLP and URL will go. Unsure about LNK...

[j_c_hallgren]

Too bad there isn't some way to hook these lists to the previewed formats config setup, though I do realize that these types include files that aren't previewable... hummmm...

[admin]

Too bad there isn't some way to hook these lists to the previewed formats config setup, though I do realize that these types include files that aren't previewable... hummmm...

That's the problem. The preview is not just a machine where you throw extensions at. There's a huge amount of code behind the preview, almost each extension needs special care. And in many cases, the environment decides whether a preview works or not.

[j_c_hallgren]

Too bad there isn't some way to hook these lists to the previewed formats config setup, though I do realize that these types include files that aren't previewable... hummmm...

That's the problem. The preview is not just a machine where you throw extensions at. There's a huge amount of code behind the preview, almost each extension needs special care. And in many cases, the environment decides whether a preview works or not.

Understood...but I was just thinking that the groups/list that preview uses (and how that can be customized) could apply to this also...but how to handle those that are not previewable...that's the big problem.

So that any 'font files' types for preview would apply also to the 'find files' usage, for example...this would mean splitting some of the preview groups into separate parts, like web & office.

Anyway, it's just a suggestion to avoid redundancy in setups and also make user adjustments to what they want in a given group apply to find as well...maybe a new column/switch per extension that says 'use for find' or similar?

[abc550]

You cannot remove anything from the internal lists, though. This might be changed later if there's demand.

Surely there is demand! Please consider, that some of pre-configured extensions might in some systems belong to another group (File Type in XY terminology). Say in my system .ASP extension (pre-configured as a Web file) is associated to some specific application being actually a text file..

Furthermore a user should get an option to create his own groups instead pre-configures. Say for me .EXE, .SYS, .CFG, .INI and so on belong to the one group of files (they are program code files in binary or text format) as the opposite to .DOC, TXT. and .RTF, that is my office documents.

P.S
And it would be nice to have an option to remove this new button "Find by Files" at all from the search pane, 'cause this button in its current mode may be not worth this valuable room, which it grabs from for "Name" input box.

[abc550]

And one more thing is something I'd call "custom definition of type". If you give a user the option to assign any part of the filename, not only the last part (extension), it would add the next step of usability in search. Say you need to make many sequence searches with the words "AAA and BBB", while all other parts of search inquire are various. Yes, you can simply enter all, what you need in the existing name field:
(AAA) and CCC or DDD and EEE
and than
(AAA) and PPP or RRR" and TTT
and so on. So you need every time edit the inquire text, that is teplace only the part of it and leave the other part. Please try to do so 10 times at a stretch, and you for sure you'll see, that it is a quite cumbersome work.

But it could be much more convenient, if you involve the second input box:
CCC or DDD and EEE AAA
PPP or RRR and TTT AAA
and so on.

[admin]

Thanks for the input. I will come back to this feature in a few months. There has not been much feedback yet from users.

[abc550]

Thank you, Donald!
However could you please consider to add the option to disable this new box in the meanwhile (via Configuration menu). For those, who use long inquires in Name box, the lack of the room is now a real headache (and the advantage from the new feature is not enough to cover this disadvantage).

[admin]

Thank you, Donald!
However could you please consider to add the option to disable this new box in the meanwhile (via Configuration menu). For those, who use long inquires in Name box, the lack of the room is now a real headache (and the advantage from the new feature is not enough to cover this disadvantage).

I'd rather make the whole Find Files UI 100 pixels wider. That would also make space for one or two more checkboxes (ideas for these will come once the space is there ). But not 100% sure about monitor widths. People on 1024x786 will get problems then... hmm. Or the rubber approach as done in the Preview and raw View. But then the Find Now button will be very far out to the East... hmm...

PS: Taking away certain interface elements would not play well together with search templates and search results caching. I'd rather avoid this route.