I hope I can explain myself clearly. Using the renaming script to obtain column values I have found this situation, which I don't know why, besides being a bit confusing.
Previous steps:
Now select a file and open the Advanced Rename dialog and the Script Log.
Use the preset test1, it should show: keyword with //**() and spaces#1#keyword with //**() but no spacesEND
Instead, it shows: keyword with //**() and spaces#1#keyword with //**() and spacesEND
It shows Evaluator column EvCol1 twice, maybe because keyword for EvCol1 and EvCol3 are the same but for the spaces.
Now use the preset test2. You can see that the values at the end are not parsed. Why is that?
Use the preset test3. See that there's no problem while obtaining the values. Is the same as test2 preset, only that this one is using the Evaluator column EvCol2, and preset test2 use EvCol3 column (it happens also with EvCol1). Again, why?
In the point 6, that preset works if you limit the keywords up to 33. Now one might think that this is due to a pattern length limit, but in the preset test3, which is exactly the same, except for the last keyword, all 66 keyword are allowed to be used without problems...
I don’t fully understand what you’re doing but I doubt that using Rename as a way to run Evaluator code will work well in general. I’m surprised the data isn’t being filtered for path/wildcard characters etc.
We might be able to provide a proper way to do what you need, if you tell us the details of what you need.
@Leo is about getting values for script/Evaluator columns (mostly related tothis post. )
AFAIK, besides abusing Rename Scripts, there's no other way to obtain those values for that purpose. And I was using Evaluator Val() function to embed code (using {=..=}) precisely because with that you can obtain the value without characters being replaced or filtered. And to avoid having to run multiple "renames", I group them into a single pattern to use in a preset. But sometimes the problems mentioned above happens.
I think being able to get the value of a script/Evaluator column via scripting without having to resort to these "tricks" would be very welcome.
Thanks Leo. Yes I am aware, but I don't think it will be of much help since:
The column must be visible in order to use PRINT.
In some tests I did, using PRINT is way slower than obtaining the values directly from the object properties (when available), even slower than abusing Rename Scripts, specially when there's multiple files involved.
You can give Print a format that has different columns in it. I think it may need to be predefined, though. We could probably make it accept a scripting Format object so you could build the list of columns via scripting.
I wouldn't expect Print to be that slow in CSV/TSV mode, which is what you'd want to use with a script. Plain text can be slow due to calculating all the column widths.
It is. I remember when I made a FAYT command which is basically like Filter Mode but with the possibility to search in all columns, and at the beginning I was using PRINT to get the values, and because of the fact that in folders with many items, you got the "Printing..." message, I decided to look for other methods. Getting the data directly from the Item object, for the built-in columns, was about 3 times faster on average. For script columns, using a Filter object, the difference was similar.
Maybe something like DOpusFactory's GetShellProperty() method but for other values is something doable in the medium term?