[F] Evaluating placeholders before saving

bug-fixed

#1
Thread split from here

--

There is support for that, but if you want to use scripting functions you'll have to swap your tags through the filename.

P.S.
ALBUM='%artist%' puts 'Beatles' into the ALBUM field as you would expect. The scripting functions do not work however.

'$caps("%artist%")' comes out '$caps("Beatles")'

PPS
This appears to work in the grid, but as I later found out, '%artist%' is written to the tag and not 'Beatles', although showing as such in the grid.


#2

:huh:


#3
QUOTE (Sebastian Mares @ Aug 18 2004, 08:51 AM)

:huh:

Actually, neither of them work! Although entering '%artist%' in the ALBUM field either on the left or in the grid translates to 'Beatles' in the grid, this is deceptive. '%artist%' is actually written to the tag! I think Florian will have to decide whether to support all, including the scripting functions, or none in this area.


Übernahme von Tags aus Dateinamen
#4

It's definitely not WYSIWYG, so I would say it's a bug! Does your two-step conversion involve going through the filename? I know it can be done with an action, but that seems to be a little involved timewise unless you are working with a lot of files.

Will Florian be back soon?


#5
QUOTE (Rijkstra @ Aug 18 2004, 04:53 PM)
QUOTE (Sebastian Mares @ Aug 18 2004, 08:51 AM)

:huh:

Actually, neither of them work! Although entering '%artist%' in the ALBUM field either on the left or in the grid translates to 'Beatles' in the grid, this is deceptive. '%artist%' is actually written to the tag! ...


This must be a low-priority bug. A month has gone by and Florian as yet too acknowledge it. It still behaves the same way in v2.25. The bug is very obvious when you look at the tag in a program other than Mp3tag.

#6
QUOTE (Rijkstra @ Sep 21 2004, 09:39 AM)
QUOTE (Rijkstra @ Aug 18 2004, 04:53 PM)
QUOTE (Sebastian Mares @ Aug 18 2004, 08:51 AM)

:huh:

Actually, neither of them work! Although entering '%artist%' in the ALBUM field either on the left or in the grid translates to 'Beatles' in the grid, this is deceptive. '%artist%' is actually written to the tag! ...


This must be a low-priority bug. A month has gone by and Florian as yet too acknowledge it. It still behaves the same way in v2.25. The bug is very obvious when you look at the tag in a program other than Mp3tag.

I'll take this as a feature request. Thanks for the reminder :slight_smile:

I can't do anything about evaluating placeholders which are already written to the file (like your %artist% above) but I'll try to evaluate them before saving them to the tag when editing via the file view.

Best regards,
~ Florian


#7

I just decided, that this is not a bug but a missing feature you're suggesting.

Best regards,
~ Florian


#8

I don't agree that it is just a missing feature. It's a deceptive bug. Since %artist% visually translates to its value in the grid then that's what should be saved with the tag. Either it should do that or you should remove the misleading What-you-see-is-NOT-what-you-get conversion!


#9

I understand what you mean and moved the topic back to "Bug Reports".

I'll try to fix the problem.

Best regards,
~ Florian


#10

Rijkstra,

could you please try the latest Development Build?

Thanks!
~ Florian


#11

Good! It is working now when you enter a placeholder in the grid. I saw 'John Lennon' where I expected to see %artist% after saving. Unfortunately entering %artist% in the grid isn't compatible with entering %artist% in the tag window. There is no direct conversion from that combobox which you would have to use on a multiselect where the feature would be most powerful. You can consider completing that entry equivalency as a feature request. Thanks for the feature/bug fix!

There is now a two-step process for translating multiple records with a common placeholder into text by a quick cell-by-cell edit in the grid once the placeholders have been written.