Feature request: %_appdata% for Exports?

I recently did a lot of Exports to Batch Files in order to handle special stuff with external programs, and for automated cover image handling (using ImageMagick).

I started out writing a Process.bat batch file that actually handles the data the export generates (and takes care of OEM character set conversion). This file is always the same and I stored it in MP3Tag’s program directory.

For creating the (temporary) Process-Data.txt batch file (which gets generated by MP3Tag’s Export), I’d have it also stored in the same place, but of course this poses problems for Vista users (and if more than one user uses the same computer). So I’d like to store my temporary files in the system’s defined Application Data path, defined by the environment variable %APPDATA%, i.e. store it as

%_appdata%\Mp3tag\data\temp\Process-Data.txt

which the system would reference as something like

C:\Documents and Settings\moonbase\Application Data\Mp3tag\data\temp\Process-Data.txt

and which I could reference in my Process.bat »main« batch file as

%APPDATA%\Mp3tag\data\temp\Process-Data.txt.

All this would allow for a safe, XP- and Vista-compatible, easy way to handle Export-generated batch file stuff from within Mp3tag. One could even (as I did), put a little icon »Process Mp3tag-generated Batch Export« next to the Mp3tag icon in the Quicklaunch Bar — making for a two-click »DO IT!« :wink:

For all this, I’d like to ask for a new Mp3tag variable called %_appdata% that resembles the environment’s %APPDATA%.

Thinking about it a second time, maybe it would be wiser to use the system’s TEMP path instead? (%APPDATA% is usually a »system« folder, not all users know how to »unhide« it.)

Maybe we could get both %_appdata% and %_temp%?

What do you feel about this?

Hi,

until today I'm not so into MP3tag (because the most files I have are WAV's) but ...

I think the info (tags) of a file should be "local" (itself) and no info from outside / above / parent (the directory).

In programmers world this would be the same as storing the parent reference in the child object (and then the parent dies :w00t: ... purists would kill you :sunglasses:

I'm sure there is another solution :book: - that's the daily business with environment, users & rights. :music:

Can this put you further on?

DD.20081017.1512.CEST


Talking about »ideal« environments: We don’t have them. (Maybe because too many guys in Redmont stored parent pointers in child nodes :wink:) Otherwise we wouldn’t need batch files …

Great suggestion, Detlev! For a Tool, that’s a real neat idea.

Only I was looking for something to be put into an Export’s $filename, like

$filename(%_temp%\Process-Data.txt',utf-16)

or
$filename(%_appdata%\Mp3tag\temp\Process-Data.txt',utf-16)

Here comes a new item to the long list of workarounds for Mp3tag.
Moonbase, please give the attached DOS cmd file a try.
Read description in the remark section of the cmd file.

If the cmd file is invoked along resp. before starting Mp3tag, e. g. via a common cmd starterfile or some shortcut anyway, then the newly created GetPath.AppData.mta will be always there in th actions folder to let it run when it will be needed.

The newly created user tagfield APPDATA should be removed from the file/s after usage but this task is left to the user.

GetPath.AppData.cmd.txt (1.11 KB)
DD.20081017.1814.CEST

To invoke the GetPath.AppData.cmd file from within Mp3tag you can use the Tools menu.
Here is a section to put into tools.ini (%APPDATA%\Mp3tag\data\tools.ini):

[#0]
MTTOOLSNAME=GetPath.AppData
MTTOOLSPARAM=/c""%%appdata%%\\\\Mp3tag\\\\data\\\\actions\\\\GetPath.AppData.cmd""
MTTOOLSPATH=C:\\\\WINDOWS\\\\system32\\\\cmd.exe
MTTOOLSINST=0

DD.20081017.1938.CEST

GetPath.AppData.cmd.txt (1.11 KB)