Drag & Drop to Move Files
Drag & drop within the application can be used to move files from one directory to another in disk images with hierarchical filesystems, such as ProDOS and HFS.
When moving files within a disk directory hierarchy, all selected files are transferred to the target directory. If you select a variety of files from multiple directories, all of them will be moved to the destination. If you want to retain the directory structure, move a directory instead of the files inside it.
Unlike inter-application copies, the behavior is not affected by whether the display is configured to show all files or only a single directory.
Dragging a file to the directory it already lives in has no effect.
Files may be dropped in the file list or directory tree. If dropped in the file list, the application checks to see if they were dropped on a directory entry. If so, that directory will be used as the destination; if not, the directory that is currently selected in the directory tree will be used.
The order in which files appear in a directory can be important, so an effort is made to preserve the order of the files. They will generally be moved in the order in which they appear in the file list on screen.
Copy & paste within a file archive is not permitted, because it's not possible to read from an entry while modifying the archive. Copy & paste within a disk image is allowed, but attempting to copy a file onto itself will fail.
Drag / Copy Between Applications
Inter-application Drag and Copy operations can be initiated from the file list. They two have identical behavior behind the scenes: in both cases, a collection of "virtual" file references and metadata is collected and provided to Windows. The file data itself is not copied to the clipboard. Using virtual file streams improves performance when starting a drag or copy operation, and allows files to be dragged or pasted directly into "foreign" applications, such as Windows Explorer.
Data is read from the virtual streams at the time the files are dropped or pasted. Because of this, files copied onto the clipboard cannot be pasted after the source archive or disk image is closed. Similarly, files copied to the clipboard cannot be pasted if they are deleted from a disk image or file archive after being copied. This means you can't copy files between disk images by opening the first image, copying the data, closing it, and then opening the second image to do the paste.
If you copy a disk image or file archive that is contained within another archive and is currently open in the Archive tree, it will be closed automatically when copied.
The application has no ability to influence how Windows Explorer handles the clipboard data prepared for "foreign" transfers, so the file data must be arranged in the clipboard in a way that allows it to be written to Windows without further action. This requires separating data and resource forks into separate file entries, with filenames and file contents appropriate for Windows and the currently-selected attribute preservation system (NAPS, AppleSingle, etc).
When dragging or copying between instances of CiderPress II, a different set of metadata and virtual file streams is used. These copy both forks and all file attributes. Certain options, such as "strip paths" and "use raw data", will change how the data is placed on the clipboard.
Files may be dropped into the file list or the directory tree, from a drag initiated from another application instance or from Windows Explorer. If dropped in the file list, we check to see if they were dropped on a directory. If so, we use that directory as target; if not, we use the current directory. When pasting (with Edit > Paste or Ctrl+V), the directory currently selected in the directory tree is always used as the destination.
The order in which files appear in a directory can be important, so an effort is made to preserve the order when copying them. However, directory entries need to come before any entries that use them, to ensure that the appropriate hierarchy is established before trying to create the files.
Dragging in From Windows Explorer
Files dragged from a Windows Explorer window are presented to CiderPress II as a list of filenames. This works like any other add/import operation.
The exception to this is when Windows Explorer is treating a ZIP archive as if it were part of the filesystem. In this case, the files are delivered as metadata and virtual file streams. This mode of operation is not currently supported.
Partial Pathname Handling
Suppose we have an HFS disk image with the following set of files:
MyDocs
AddressList.csv
FavoriteThings.txt
FancyText.doc
MyPhotos
Rocks.jpg
Family.gif
Vacation
Snow.jpg
Resort.gif
If we copy these to the clipboard, what should the filenames be set to? Specifically, if the file list is just showing the contents of the "Vacation" directory, and we copy "Snow.jpg", should it get pasted in Windows Explorer as "Snow.jpg", or under a couple of directories as "MyPhotos/Vacation/Snow.jpg"?
The expected result of pasting or dropping the files in a different window will depend on how the files were being listed in CiderPress II. If the application was only displaying the contents of the "Vacation" directory, it would be reasonable to drop the file as "Snow.jpg". However, if the application was showing the full file list, then the user would expect the directory hierarchy to be preserved because that's what's shown on screen.
This is independent of the "strip paths" option, which always removes all paths. For example, when viewing just the "MyPhotos" directory, extracting the "Vacation" folder should extract "Vacation/Snow.jpg" and "Vacation/Resort.gif". With full paths those would further be stored in a "MyPhotos" folder, while with stripped paths it would just create "Snow.jpg" and "Resort.gif" in the target folder.
The behavior in the single-folder view matches Windows Explorer drag & drop behavior, because Explorer is effectively always showing a single folder.
Using the current view mode as the determinant of the behavior has one notable drawback: CiderPress II always displays file archives in full-list mode. While it's possible to fully strip the directories with the "strip paths" option, it's not possible to specify a partial path hierarchy. (This could be resolved by synthesizing a directory hierarchy for file archives.)
It's worth noting that this feature works the same way that "extract" does: files extracted from the single-directory view will be "rooted" in that directory, but files extracted from the full file list will be extracted with their full paths.
When files are copied between instances of CiderPress II, the receiving application also has an opportunity to strip paths from the incoming files. (The "strip paths" option is configured separately for add operations and extract operations.)
DOS 3.x File Handling
There are two additional considerations when working with files on DOS disks: "raw" mode and text file character conversion.
It's important to pay attention to the "raw files" setting when copying files from a DOS disk, because it determines how the data will be formed on the clipboard. It should generally be enabled for DOS-to-DOS transfers and disabled for anything else. Setting it on the receiving side is not necessary, as the mode flag is passed along with the extended attribute data.
DOS text files have the high bit set on every character, while ProDOS and other filesystems store text files with the high bit clear. A conversion can optionally be applied when copying and pasting files within or between instances of CiderPress II. The conversion does not affect files copied to or from other applications, such as Windows Explorer, but that can be accomplished using the import/export text feature. The conversion is only enabled when copying to a filesystem, e.g. from DOS to ProDOS, ProDOS to DOS, or NuFX to DOS, but not DOS to NuFX. The Convert DOS Text option must be enabled in the application settings on the receiving side.
Add/Extract vs. Import/Export
CiderPress II uses "add" and "extract" to preserve file contents, and "import" and "export" to convert file contents. Both modes have their uses when dragging and copying, so we need a way to tell the application which mode to use.
A simple button on the toolbar determines whether "extract" or "export" mode will be used. Set Drag & Copy Mode to Add/Extract or Import/Export as needed. The behavior is otherwise the same as it would be if that menu command were chosen. The various options can be set in the options bar on the right side of the window.
If the export conversion mode is set to a specific type, rather than "best", then only the items suited for conversion will be exported.
When transferring files between CiderPress II instances, the mode must be set to "extract". If the mode is set to "export", the direct-transfer data will not be placed on the clipboard. Attempting to paste exported data into CiderPress II will result an error message.
Miscellaneous
Windows tries to prevent drag & drop operations between applications with different privilege levels when UAC (User Access Control) is enabled. Windows Explorer does not usually run as administrator, so if you run CiderPress II with elevated privileges, e.g. to gain access to physical media, you may not be able to drag files in and out.
If no archive is open in the application, dropping a file from Windows Explorer into the main application window will cause CiderPress II to try to open that file.