I don't believe this behaviour is an intended feature:
If you drag & drop a files from Mp3Tag to some externel software (i.e. Audacity, Mp3 Quality Modifier) these files vanish from the list-view-frame.
You have to refresh the view to get them back again.
This has already been declared to be no bug:
The suggested solution with CTRL does work in Audacity but not in my other example "Mp3 Quality -Modifier".
Anyway this is a very irritating and unexpected behaviour.
You don't expect it and you often do not notice that some files have vanished from the view. Therefore further actions and convertions my not apply on all files.
And having loaded some thousands of files and there is a need for refreshment because of this behaviour is also not so pleasing.
It also is not a behaviour that is only influenced by the receiving piece of software. If I drag & drop from Foobar to MP3 Quality Modifier these files do not vanish in Foobar.
Well, you can of course program a source application to treat any D&D-action as a copy action regardless of what the receiving application tells you.
The function in itself is according to the Windows interaction standard.
And I am not sure if a re-mapping would really make sense: If you D&D files from MP3tag to e.g. audacity or WinMp3Packer, it is very likely that they modify the files and they have to be read again by MP3tag to update all the information. I could even be that the original file is moved to a different location or deleted alltogether.
E.g. if you have a filter that filters for VBR files, you treat them with WinMp3packer to become CBR ones ... then the filter would show an invalid data set.
So the uneasiness
is only too justified as neither behaviour - keeping or removing files from the files list - leads to the desired certainty if files are modified by other programs outside the control of MP3tag.
It is not a question of copy or move.
Besides the features of copy and move (known from the explorer) there is also a feature of delivering one or more files to another apllication for further treatment.
Most of the software I use (players, graphic software, Editors, Office ...) is able to handle that and I never before saw that this D&D had any influence on the source.
That Mp3Tag acts like this has certainly to do with the other software. You can also see that because it does not happen with all software and it is different
ie. it happens with
- Audacity but can be avoided with CTRL
- Mp3 Quality Modifier (cannot be avoided)
and it does not happen with
- Players I know
I think the correct behaviour would be that it does not happen at all while delivering files to other apllications (which has nothing to do with copy and move).
That it is not completely dependend on the receiving piece of software is observable with Foobar that does not behave like this with MP3 Quality Modifier.
The problem of showing files with perhaps changed data cannot be avoided by hiding these files after D&D. This problem is always immanent and to really avoid it you would have to use a watchdog that registers every change of the loaded files.
MP3Tag has no influence what other software does with its loaded files.
Even if the files have vanished in the list view after D&D you can get them back with a refresh and afterwards modify them them with the receiving software.
And you can load these files directly (without D&D) with other applications to treat them while they are also loaded and displayed in MP3Tag.
And even software like players or. i.e. MP3DirectCut with which MP3Tag does not hide delivered files after D&D are able to change the delivered data and MP3Tag will only notice this with a refesh.
All this shows that hiding files after D&D is not suitable as protection mechanism.
It is only an unexpected behaviour that should be avoided if possible.
Maybe there are german explanations, which can help to understand Drag, DragCopy, Drop and the usage of the related keyboard shortcuts ...
This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.