Filenames that display as three columns

My filenames display as three columns.
080813 429344 67181.jpg

Currently when I sort its contingent on the first column, 080813, and everything thereafter. My directories holds several thousand records. My need is to be able to sort on the second value in the filename, 429344. I doubt if it matters, but I am using "File Filter Box" to search on different values.

How is it possible to have the second column of the filename sort. All the columns are equal, and always in the same place. So my filename has three values that have the following size.
080813 first column of the filename always six character.
429344 second column and always has six characters
67181 third column and is always five characters.

The use of the word columns in my above example is actually not columns, but yet they are, if that makes sense.


It's probably a good idea to mention that I switched to Opus11.

The only way to do that is to copy/move the second set of numbers in each filename to somewhere else so you can sort by that.

e.g. You could rename the files so the first two numbers were swapped. Or you could use a script that sets the Description of each file to the 2nd number, and then sort by the description column. (But you'd have to re-run the script each time new files appeared, or old ones were renamed.)

[quote="amerifax"]My filenames display as three columns.
080813 429344 67181.jpg[/quote]
These filenames are just long strings with embedded spaces. They have a consistent 6-6-5 substring layout so they look like "columns". Normal sorting will sort by the complete left to right string. If you want to sort by the middle 6-digit substring, you could rename the files to re-order the substring groups from 1-2-3 to 2-3-1 or 2-1-3 depending on the relative priority of the other two groups.

If your objective is to find/filter a specific set of files with the same (known) middle substring group you can easily do that with the built-in filter. Using your example name above, you could filter all files with middle group = 429344 using the filter * 429344 *

Regards, AB

The filename method that I'm using cannot be altered. many other processes. I use are very dependent on the date being the first location. The next group of numbers being the unique number for each document, and the last is the location the permit came from. So many times I half do a search on that middle, unique number, value. Then I have to sort based on that number. Sometimes I have to use a filter on that location, last group of numbers.

Here is a thought on how it would work, but I have absolutely no idea on how bizarre this would be. They are all JPEG files.
011814 432346 13251.jpg

  1. Rename the file using the middle value. 432246.jpg. I'm sure this could be done with a macro.
  2. Once I have accomplished my needs. I would then change the name back to 011814 432346 13251.jpg

That would work only if I could somehow pull 011814 432346 13251.jpg out of the air.

As I'm typing this my wheels are starting to spin a bit.

  1. Rename the file 432246-011814 432346 13251.jpg
  2. The "-" might act as a locator.

Since I'm doing this daily. I'm doing the searching based on this sort twenty to forty times a day. A perfect solution would have been that the system could automatically look at a value within the filename and give me the ability to sort.

Because the positions and values are the same in every record this would be workable. The problem is finding a way to do this. Not asking for much am I.



What you are asking for are customizable sort keys based on some calculation, but they don't exist in DOpus. So you'll need another field filled with the sort key, and you'll sort on that. That is the technique Leo had mentioned.

I'm no regex wizard, so there are simpler expressions perhaps, but this should be specific enough to do a regex rename that'd work:

Old name: ([0-9][0-9][0-9][0-9][0-9][0-9]) ([0-9][0-9][0-9][0-9][0-9][0-9]) (.*)
New name: \2_____\0

...and when you're done, just do an UNDO?

To put it back if you can't UNDO for some reason:

Old name: ([0-9][0-9][0-9][0-9][0-9][0-9])_____(.*)
New name: \2

Not to seem dumb,it times I wounder. But. New name: \2_____\0
_______ not sure what this would be.

Also thanks for pointing me.


This was to help you re-name the files back to their originals. It is called a "marker", something that you know probably won't exist in your file names, so can reliably be used as the separator between the old and new names. You're swapping: your original names with a New component followed by ________ followed by the Original name. Later, you strip out the New_______ to rename the files back to their original names.

Yeah - just as MrC said :slight_smile:...

Personal preference more than anything really. Anytime "I" have found myself resorting to doing ~temporary rename tricks in order to distinguish files from one another, I've always preferred to use an unusual rename convention to make them stand out in a more obvious way. Mainly so I have something super obvious to remind myself I need to 'put things back to normal'. Not a necessary thing, and you can certainly swap it out for any other character or sequence of characters that help you isolate those files from the original file name convention.

If you were to just use something like ([0-9][0-9][0-9][0-9][0-9][0-9]) (.*) to rename things BACK, then Opus would match that pattern to all of the 'other' files you may NOT have renamed, so you'll want ~something to easily distinguish which files to rename BACK to their original names. Alternatively, you could just be more specific with the use of regex, but that just looks like a much longer expression.

REMINDER TO MYSELF TO POSSIBLY OPEN ANOTHER THREAD RELATED TO THIS, it might have been a bit simpler of an expression using the QUANTIFIER token, but it didn't work as I expected in my test based on reading the manual... i.e. if I used something like ([0-9]){6}, it matched a pattern of numbers UP UNTIL 6 (so 3 digits in the component of the name, or 4, or 5 - though not MORE than 6), and that's not how I expected it to work given the manual's description of the QUANTIFIER token matching an "exact" number of expressions...

There's another way to skin this cat. You could create links to these files in the folder, with the new names in a new folder, and use that folder view to sort on. Then, just toss the folder full of links when you're done. That way, no renames, and this works on read-only media.

I think that solution would be possibility of creating a custom columns which would contain strings produced by some operation on title (and/or on other attributes of files/directories), e.g. results of some regular expression.
Probably not something possible in current version of DO, so this is a suggestion/feature request.

That's essentially the idea that Leo proposed.

(But you [would not need to] have to re-run the script each time new files appeared, or old ones were renamed.)

to paraphrase Leo. :wink:

A cool DOpus feature would be a filename transformation overlay view, where a virtual view could be shown of filenames which have undergone some find/replace or regex transformation. So files names such as:


would appear in the overlay view, with a transformation of (.)_(.).txt => \2_\1.txt, as the sorted:


This would allow users to construct virtual names, which could be used for sorting / viewing purposes, and no renames or file modifications would be required.

Interesting idea, Mr C.

Regards, AB

I know some of you have posted (recently in fact) about this very same topic - around having a way to specify a custom sort.

I think a bit of what MrC has suggested here makes the most sense... where perhaps users could specify one or more user defined fields that could be added to the list of sortable column fields and have their values calculated by Opus based on criteria the user could enter - which in most cases would probably be some sort of regex action. Then, as Konrad suggested, you don't need to actively modify file metadata every time you want to take advantage of such a thing.

That said, I think it's worth pointing out that you can already add custom columns and other sorts of things to Opus via a VFSPlugin. So, while there are fewer ppl out here with the skills or inclination to do such a thing - GPSoft might prefer to leave this sort of thing to that interface rather than coding everything directly into Opus themselves. Let's see what they say - I don't recall their comments on the previous threads some of you had going on the whole 'custom sort' topic... One that that might be interesting if someone were to write such a thing would be if GPSoft might then consider allowing us to turn OFF the regular filename column - which I've wanted to do in the past when printing folder output to a file and other scenarios...

I've started and abandoned like 4 different plugins over the years... this one seems fairly straight forward - so maybe I'll dabble now that I've tried my hand at a bunch of scripting projects. I'll see about grabbing one of the VS Express packages from MS this weekend - I think they're still free for personal use...

You could write a VFS plugin that changes what's in the filename column (when you view a folder via the plugin's URL prefix), which will get you custom sorting. No need to turn the column off and populate a different column; change what's in the main column instead.

Yeah, it occurred to me later that I was locked in on a heavier-weight solution that I'd used 20 years ago, with a virtual file system view. And was going to follow-up on my post (but got busy in a meeting), adding that a far better solution would be custom expression columns for a view (I use these all the time in JRiver's Media Center, and they are awesome). Some basic functions, including regular expression replacements, with access to metadata fields, would really add some neat power here.

If you want to add a custom column, rather than change what's in the name column, a standard shell extension can do that and is probably less work than writing a VFS plugin.

(IColumnProvider extensions are still supported by Opus, even though Explorer ignores them from Vista onwards).