Select by filename list is broken
obviously a major tool for selecting hundreds of client selects and organising quickly is the 'select by filename list' option in the menubar.
unfortunately since 22 this is now broken, and random files that are not in the list are being selected making this tool unusable.
Using OSX:
The most common scenario is client will send back the low res of their selects.
previously you could select all these jpgs CMD+A and copy CMD+C
then simply paste into the 'select by filename list' window in C1
using delimiter - new line and ignore file extension
this used to work perfectly. now it does not.
PLEASE FIX THIS ASAP
thank you
-
not the right audience.
1 -
Thanks champ. done that.
I'll leave it here to see if the community has helpful input.
1 -
Bummer. Not that that's helpful, but always sad to hear an existing workflow has been crushed.
0 -
Dan,
Can you provide some examples of "right" and "wrong" selections of files? Are they totally random or do the names have some sort of commonality that might possibly be confusing the search and select functionality?
"The most common scenario is client will send back the low res of their selects.
previously you could select all these jpgs CMD+A and copy CMD+C"
Where are you creating the list from?
A screen display? Using what sort of screen presentation application?
0 -
SFA
I did some further testing and tried to find the commonality.
It appears the search function does not have the ability to search for the specific filename and reject any filenames that may also contain the desired filename but are a different image.
for example searching for 'imagename_1.jpg' will also return files named
'imagename_10.raw' & 'imagename_11.raw' & 'imagename_12.raw' etc etc
so technically it is doing the right thing but its not correct.
creating and selecting the list is as simple as actually selecting the low res jpegs in a finder window, pressing copy CMD+C and then pasting into the 'select by filename list' window
you can test this by processing some files from a session. navigating to them in finder to them and CMD+C
you can confirm that this works by pasting into 'text edit' application using the 'paste and match style' CMD+OPTION+SHIFT+V option from the edit dropdown menu. CMD+V will just paste the images.
0 -
This came up on another thread a week or two back, but from a slightly different starting point.
That said I'm surprised that including the file extension in full still discovers and selects the other examples listed.
As a Windows (10) user I don't think I have the same copy file name options within Windows but it seems there may be an add-in that one can install to undertake the task.
In Windows (looking at a single file) if one attempts to edit a name (or use that function as a source to access a copy name option) by default the file extension is excluded. so no ".jpg" for example.
In that situation the search matches what is left of the name - so in your example the only match is to "imagename_1" and any files with names starting with the same string.
Would I be correct to think that you want the file names but NOT the file extensions for you selection purposes? If so the ".", if it was included, would likely give you the list you expect.
How you might get to that point I'm not sure and why you might need to get to that point, if everything worked previously, I have no idea.
0 -
I have just tested again, you are correct, if the filename includes the period '.' at the end of the name before the extension the search function selects the files correctly, but the checkbox for 'ignore file extension' must be unchecked.
eg 'imagename_1.' 'imagename_2.'
so it appears this checkbox function needs to be re-coded to leave the period '.' and only ignore the characters afterwards such as 'jpg'
0 -
Yep, but unfortunately both OS's think of the extension as including the "."
Other than having a different file name structure that eliminates the anomalies (which is what I tend to do simply to avoid file sorting challenges - in all applications, not just C1) the only solution that comes to mind is to add a mid-action process that takes the list produced by the copy activity and adds the required "."
So far as I know, at least on Windows, nothing about the search processing based on the list (however it has been created) has changed in recent versions.
The smart approach to the problem (to allow more control than just the use of ".") would be to allow the user to specify a character or string to append to the main search string (i.e. the file name before the "." or whatever) in order to truncate the subsequent search. However, that starts to become more complicated than may be required to limit just the numeric part of the string as per your requirements.
Currently, your only option might be to resort to an Advanced Search (if the concept of adding the "."s to the copied list is not practical.
0 -
In such cases I usually fire up a spreadsheet application (numbers or excel) copy the file list (in whatever form it comes - lowres-files or email-text with commas or every file a new line) and try to add a second column which (combined with the image name) adds up to a very specific search string.
source:
image4231; image5243;spreadsheet:
"image4231" + "_acme" = "image4231_acme"search string:
image4231_acme; image5243_acme;0 -
search and replace also comes in handy...
0
Post ist für Kommentare geschlossen.
Kommentare
10 Kommentare