I don't see any way to display the "file type group" as a column. Am I missing something?
Looks like there is no such column. I think they are rather an internal help structure to handle type sensitive context menues
or "open with program x" things, & therefore weren´t considered to make much sense as a column type.
I would love to see it available as a column for search rather than searching for multiple extensions (avi, mpg, etc). But in this particular instance I was trying to figure out why DO was not using the right Folder View to display a directory. Ultimately I was able to figure it out but it would've been nice to see the groupings so I could tell if maybe my % was too high or in my case where it was close to 100% it was using the default network setting layout because the option had been turned off at some point. Maybe during an upgrade I don't know for sure as I don't recall changing it. But if nothing else it's a good verification.
I should also suggest that these functions within DO start using the same lingo (ie column names). For example in "search" there is a "type" but it's not the "File Type Group" and under "column headings" you have "type" but again not the same type as what is listed under "search", even though it initially appears to be the same type, there are very slight spelling differences on some. You have "extension" under columns but not under search and it all becomes very confusing as to what's truly what and where you use what field.
You can find by file type group using grp: wildcards. See here in the manual.
You mean Find, not Search, right?
File Type Groups are not the same as File Types. It might make sense to have a separate File Type Group column but if you think the Type column should show the File Type Group instead then I think there's some confusion somewhere...
Can you give an example of what's different to clarify exactly what you mean?
Not sure why you'd want a special Extension clause for Find or Filters. You can just use a simple Name wildcard.
Yes by search I mean find. It sounds odd to me to say find a file because find is the result of a search, you find something after you search for it. IF you lose your keys you don't find them until you search for them.
Here are some of the prior examples I have posted to the board:
Again these are examples of inconsistent treatment of ideas and they cause confusion. The confusion doubles because they are not functions/choices that one uses regularly and all the more why they need to be named consistently so the confusion doesn't occur.
You have one of the best file handlers on the market in my opinion and I'd like to keep it that way.
You're right on with "name"; you can use the wildcard pattern as I learned in one of these prior posts but having grown up during DOS and Windows Explorer these fields have always been maintained almost as though they were different fields. If DO is going to maintain them as a single field then why offer columns of extension and extension (dir) (which I have no clue what this even represents just more of the confusion) when you cannot "search" on them. To me if I see a column then I should be able to search using that column and use that column for whatever function resides within DO. And conversely when I don't see a column like the File Type Group which to me I should be able to see it just adds to that confusion as to what's available when and what does it mean within the context I"m currently working under.
What I'm trying to suggest is that there needs to be consistency across the product so that way it maintains it ease of use for all customers and doesn't require a trip out to the boards to figure out what should be basic functionality. The boards should be more for the obscure functions like DO code and setting up function buttons not trying to figure out what a column name means and why the column means one thing in this function and doesn't appear in another or appears but means something entirely different. As long as you can display that column within a lister everyone knows or for the most part should understand by the values shown in the column what it means and from that how they can use it to find what they are looking for; to have a column that cannot be used for anything other than display or sorting serves very little purpose in my opinion.
For another example just within the lister available columns you have "size", "size (auto)", "size on disk", "size on disk (auto)" and "size on disk (relative)". I know as a former programmer that the actual size of a file is never truly the size it takes on the disk because of how a disk is formatted. But how many other people know that? But even understanding that, what is the difference between all these columns? To me you have the amount of space a file actually takes (the physical space) and the actual size of the file which will be somewhat smaller so why are there 5 choices for what really seems to be 2? What is a "relative" size? Relative to what? What is "Repeat?" listed under movies and there are a whole slew of columns that I just can't even make sense of that I think why would anyone have any reason to search or even display such obscure information and yet we can't display the "File Type Group" which has major functionality controlled by it within DO?
Finally you say you can use "grp" to search for files based on File Type Group. But how would anyone know that other than reading the manual from cover to cover? You wouldn't even know how to search the manual to find it. This is exactly what I mean that in one place it's called one thing and in another it's called something else.
The "select clause" is the perfect example of what I'm trying to explain. In SQL you have field names and if you select * from database you get a listing with all the fields (as named in the database) going across the screen. You don't select grp from database and display "File Type Group" across the top without using Select grp AS "File Type Group" from database. Secondly if the column names represent the names from the database and you have those same names within the search function then you eliminate all the confusion. I do know how to code database selects but I don't know where to code them in DO. As far as I'm aware there is no database interface or Unix like terminal where I can do my own coding which would be great assuming that I know the database names and what is stored in them.
All I am trying to say is the field choices in the find selection criteria should be the same as column names.
Find & Search are two different things now, unfortunately. I agree it's confusing, but that's where we've ended up. 
[ul][li]Find = the built-in Find functionality that's existed in Opus from day one.[/li]
[li]Search = Windows Search, which Opus 10 can also use.[/li][/ul]
[quote]Here are some of the prior examples I have posted to the board:
https://resource.dopus.com/t/a-little-clarity-on-date-time-columns/10948/1[/quote]
In the first thread, we could not reproduce what you were seeing. Appears to be something about the way some of those filetypes are in your registry (possibly only reproducible if you install certain combinations of tools in particular order, or similar). I don't doubt that you're seeing it, but it is not normal or intentional, and it's difficult to do anything about it without a way to reproduce it.
In the second thread, I explained what the difference was. If the names are unclear at first it's easy to try the different columns to see what they do, IMO.
If you want to suggest better names for them, go for it, although it might confuse people used to the current ones I guess (and either way would probably have to wait until a batch of language translations are done).
Because people wanted to be able to have the extensions all lined up in a separate column, easier to read and compare.
The extension columns add something that could not be done without them.
(You can also sort by the column, although that isn't really adding a feature if you know that you can do the same by shift-clicking the Name column. Not many people know that, though...)
In contrast, having a special Extension clause in Find filters seems redundant. What functionality does that add? It'd just clutter up the list of clauses and make people wonder why it was there.
Many of the columns show the same information in different ways. If a column only exists due to visual differences in how it presents the data, it's redundant when it comes to searching.
There's never going to be a column to display every possible piece of information. Only the columns people have actually asked for and/or that seemed useful to the developers are present. If you think a particular column is missing, just send in a feature request.
What are we supposed to do about that? Not have columns that may confuse people, even though other people have asked for them?
Note that "Size on Disk" is part of the standard Windows property dialogs and has been since Win95, I think.
Sorry but, with the Size columns, I really don't think the difference is that hard to work out, and if it is you just turn the different Size columns on and see what you get. I honestly don't see what the big deal is here, and you haven't suggested how it could be improved either.
Let's see, what could the KB and MB mean in the context of sizes? Maybe "Auto" is confusing, until you turn the column on and see what it does compared to the others. Sorry but it doesn't seem confusing to me. A little playing with the program and it is easily discoverable what the size columns do. If it wasn't we'd have lots of questions at the forum, surely.
Just turn the column on and it is obvious. What else can we do? ...This is getting ridiculous.
I've never used it myself but I'll take a wild guess and say it tells you whether or not the movie file has a flag that tells movie players to repeat the movie when it reaches the end.
Ah! The crux of the issue: Opus displays a bunch of columns other people wanted and asked for a long time ago, but not the column that you asked for recently.
If you want a column for File Type Groups, send GPSoftware a feature request.
Would you be happy with someone who didn't use File Type Groups at all complaining about the existence of a File Type Group column because he didn't use/need/understand the concept and wanted some other column (which nobody had asked for before) instead?
The various size and movie columns (or whatever) were not put there to spite people looking for a File Type Group column...
Sorry but in a powerful, complex, open-ended piece of software, some features are going to be hidden unless you read parts of the manual (or pick them up from a tutorial or forum post, etc.). For people who don't read the page explaining Opus's wildcard syntax, there are plenty of other ways to achieve similar things, so it's not exactly making the program unusable.
And the fact is. most people do not use File Type Groups at all.
You've lost me somewhat there...
You define find filters interactively, using menus of the available things that you can search on. There is no need to know what all the columns are called or how they map to filters; you just pick what you want to search for from the menu and fill in the other details.
I agree that the grp: thing is not discoverable via the UI, but that's an exception, not the rule. (And the grp: thing wasn't really added for find filters anyway. It's just a side-effect of it working in most fields that accept wildcards.)
But they're very different things.
Columns are about displaying data in a single column that is non-interactive (apart from the ability to sort them) and which should use minimal space.
Filters are about selecting data based on criteria, with a UI that lets you choose the criteria, then specify things like the units (if it's a size) using further UI elements that take up a whole line...