Drag-and-drop MAXScript Zip files

The OLE-based drag-and-drop system in MAXScript accepts the dropping of MAXScript .mzp zip packages. They can be dropped either from i-drop-enabled web pages or directly from file directories, say from the Windows Explorer or the new MAX Asset Browser.

The main use for this feature is to allow script packages to be dropped into MAX and automatically run, particularly packaged dropScripts. But, since the package can contain files of any kind, it is possible to use it to drop any set of files, say a scene file and its maps & other supporting files, or a new plug-in, etc. The mzp.run control file allows you to set up arbitrary distributions of the files in the package using the extract to, copy and move commands. This can be a useful alternative to the current i-drop package-dropping mechanism, which simply places all the downloaded files listed in the i-drop to the MAX downloads directory.

.mzp drop protocol

When a .mzp package is dropped, the sequence of events that occurs differs slightly, depending on whether it is dropped via an i-drop control or directly from a file directory.In summary, the i-drop first downloads the package and then extracts it, dropping from a file directory extracts directly from that file. Further, the 'on droppable' handler in any dropScript specified in the package is only run if the package is droped via a i-drop, dropping from a file directory is a system-controlled action that doesn't provide any drag-over callbacks in which to run the 'on droppable' test.

From an i-drop, the .mzp file is first downloaded to the <max>\downloads directory, along with any other files specified in the i-drop XML file, overwriting any files currently there. If the .mzp file is the first file in the i-drop file set, it is the prime dropped file and the following .mzp processing continues. The .mzp file is then extracted to a new temp directory, in the system's main TEMP directory, and the mzp.run control file is run. If there is no mzp.run file in the package, the first file in the .mzp package is dropped, causing whatever drop protocol is appropriate for that file type. If supplied, a typical mzp.run control file will contain extract to, move and copy commands to control the disposition of the files extracted from the package, say placing any texture files in $maps & scene files in $scenes, etc.

During this execution of the mzp.run file after initial load, all 'copy' and 'move' commands are performed, and a 'drop' command is looked for. The file specified on the drop command is remembered for later drop processing. Any 'run' , 'open' , 'import' , 'merge' , 'xref' commands are ignored. If more than one 'drop' command is found, only the first one is run.

At this point, the drop file is known, either because it was supplied on a 'drop' command in the mzp.run file or because it is the first file in the .mzp package if there was no mzp.run file or drop command. If the drop file is anything other than .ds dropScript file, the drop protocol appropriate to that file is engaged. If it is a .ds dropScript, and the drop is from an i-drop, any 'on droppable' handler in the dropscript is repeatedly run as the mouse is moved off MAX's windows, and the cursor changes to show valid drop targets. If the drag-and-drop is from a file directory, the arrow+ cursor shows, but the 'on droppable' handler is NOT called. This is a consequence of the limitations of simple file drag-and-drop in Windows. When the mouse-click is released, the 'on droppable' handler is called on the target window and object and if it returns OK or is not supplied, the 'on drop' handler is called. This protocol is identical to dropping .ds dropScript files directly, as if they were not inside a .mzp package.