Hi Jim,
As a general comment, date renamers are a "dime-a-dozen" everybody is fixated on date. Having another date renamer does nothing to set BRU apart from a crowded field. My take is that Explorer already shows me the Date:Time, why does it need repeating in the file name? However, universal EXIF renamers are nowhere to be found. Perhaps a need/market opportunity, perhaps not.
Admin wrote:At the moment, the only field that gets extracted is the "date taken" field. However there's nothing to stop me extracting the other fields too, and perhaps allowing them to be used somehow within the name. The screen is a bit crowded, so it might have to be via some clever way - ideas welcome!
You could use the DLPro Token metaphor, then every EXIF value has a recognized token and argument. You would then have a look-up table that the user would use to identify their choosen EXIF data arguments.
The look-up table would prevent interface clutter, while still maximizing user EXIF choices. My belief, any one user will only use a small set of EXIF fields, therefore "user friendlyness" is not a high priority, rather user flexibility.
Example: &A1, &T2, &S1; where "&" is always recognized in your code as the token followed by the arguments A1, T2, S1. Let's assume that you assigned T2 to focal length and A1 to the camera image number, then if I wanted those in a renamed field, it would look something like this: &A1_&T2mm. which would yield 8122_88mm.cr2 for a new file name from the Canon file Img8122.cr2
Check out DLPro's token table for Chris' solution for more ideas. Chris' solution shows some evolutionary clutter. My advice, bite the bullet, identify every EXIF field you can, and assign a logical argument day one.
When you say that the Extract Exif DATE item does nothing -it should extract the "date taken" information. Is it not doing this?
This is a classic case of coders intent and novice users lack of what to expect.
Hermit