When the format of {filepath} is Windows library built up by folders from different paths, the DO internal command Copy {filepath} will work wrong if the current sourcetab and the sourcetab which the {filepath} get from are not the same sourcetab.
But when Windows library is replaced by DO collection whose content of filepaths is the same with the Windows library, Copy {filepath} will work right.
For example, use ctrl+c to copy selected items from a Windows library to clipboard. Switch from the current tab to another. Then click the buttons you have written by script to implement a function of multipaste.You will find that it works wrong with some wrong windows occuring.
In the script button you have written, you would probably use the Command.AddFilesFromClipboard() method to get the {filepath} from the Windows library. Then, you will be surprised to find that Command.RunCommand('copy {filepath}') does not work correctly, but works correctly in DO collections.
If you just want to copy the selected files from source to destination, you would just run Copy on its own, without any {filepath}. (That's true whether it's a script or not.)
The Copy command also has no connection with the clipboard, so this part is especially confusing.
However this bug in my opinion is not cauced by "{filepath}" but DO's imperfect support for windows library. Because even if you write script without using "{filepath}",the bug will also occur like before as long as you have switched the current libray tab to another tab when clicking the script button you have writen.
For example,I am trying to paste files to multiple folders,like the gif I have uploaded just now.This is what I am trying to do:
First,use ctrl+c to copy selected items from a library to clipboard.Second, switch from the current tab to another which it will work right wihout bug if you don't switch. Third click the script buttons I have written for multipasting.
In the script button I have written, I would probably use the "Command.AddFilesFromClipboard()" method to get the "{filepath}" from the Windows library.Then,I will be surprised to find that "Command.RunCommand('Copy TO="{$SomePathSetbyMe}" ')" run by the Command object to which I have addfiles from the clipboard by ctrl+c just now ,does not work correctly, But it works OK when the tab I use ctrl+c is DO collections.
In my opinion,this bug is not cauced by "{filepath}" but DO's imperfect support for windows library. Because even if you write script without using "{filepath}",the bug will also occur like before as long as you have switched the current library tab to another tab when clicking the script button you have writen.
From what you've described, you are running the wrong command for what you want to do. The Copy command doesn't interact with the clipboard at all. The Clipboard command does that.
If you run the wrong command, you'll get unexpected results.
Perhaps I've not understood exactly what you are doing? Could you show us the whole script and explain what it aims to do?
Thanks for DO developer's great work in command.AddFilesFromClipboard's fix at the lastest beta.
However commandCopy library files from different folders can not work still in script copylib.dcf (1.2 KB) if the current sourcetab is not library. It may cause many potential bugs with the use of library frequently.
the image below is showing what bugs I was meeting.
The image shows it works fine when clicking the script button "copylib" if the current tab is lib. While it will work wrong if the current tab is another. It must be ok when copying normal files or in file collection.
It may be a little hard to build up a library of different folders just for testing the bug script. therefore,I would be so appreciated and thank if the bug caused by imperfect support for library can be fixed throughly.
Strangely，it will work fine again if the library file is one like Copy "lib://libTest/?79634de8/Downloads.lnk" ranther than copying several in library from different folders.
Thanks for introducing new ways for me. But I think the library paths should never be interacted with DO's sourcetabs. And in my opinion it should never be necessary to "Resolve" selected paths everytime just for avoiding the potential bugs if what user have selected contains libary items and need call cmd.setSource(another path) in script at the same time.
Strongly recommended to improve and fix the library bug throughoutly rather than just change the way users write scripts with many of which have aready been compeleted and have few need to modify.
