FileOps Worker Objects
The FileOps Worker Objects, FileOpsCopyWorker, FileOpsMoveWorker, and FileOpsDeleteWorker allow you to copy, move or delete files asynchronously, which may be useful when operating on a large number of files. They are equivalent to the static methods of the FileOps object to copyfile, movefile and deletefile.
To use the FileOps workers, you need to create an Object variable and set its subtype to one of the FileOps worker objects via the Select Object dialog. Alternatively, you can create an Object class and set its superclass to one of the FileOps worker objects, then create an Object variable or Object reference variable and set its subtype to the object class name. Having created the variable you can call its methods using OBJECTVAR.$methodname.
The FileOps workers work exactly like the other workers, including the ability to run the $init, $start or $run methods. They have the property $progressinterval which sets an interval in seconds, at which progress notifications are sent to the $progress method. $progressinterval defaults to the minimum value of 1 second.
For the $init method, the parameters are the same as used in the static methods to copyfile, movefile or deletefile.
The FileOps workers have an optional last parameter vTag for their $init methods. If supplied, the vTag parameter is some data that is passed to $completed in the column __tag of the row parameter. This can be used for example to identify the caller when the worker object is shared by several instances.
When $completed is called, a row is returned with the errorCode and errorText of the action; errorCode will be 0 if there is no error, otherwise a FileOps Worker error is returned, plus the error description in the errorText column.
When the $progress method is called (only if $callprogress is true), a row is returned with a column name 'progress' containing an estimated number between 0 and 100 indicating the percentage progress of the file operation. Note: the Delete worker never calls $progress, therefore progress notifications are not sent from the delete worker.
Note that if you try to cancel a FileOps worker while it is running, the main thread will be blocked until the worker finishes its job.
The main thread is not locked when a FileOps worker is getting cancelled, that is, either directly through a call to $cancel, or through the FileOps worker variable going out of scope. You should note that the FileOps worker will still execute in the background even when cancelled.