User (Old forums)MemberSeptember 25, 2009 at 8:46 amPost count: 23064
I do a loop and I zip a file at each iteration.
When the loop ends, the zipping is not finished (I see the zips are still coming in the working directory).
Is the zipping asynchronous? is it possible to make it synchronous?
I use the following code to zip : diskFolder.CopyFilesTo(archief,
Thanks for your help
Imported from legacy forums. Posted by Jean Christophe (had 1842 views)Xceed SupportMemberOctober 2, 2009 at 11:15 amPost count: 5658
Hi Jean Christophe,
Xceed Zip for .Net does not support Asynchronous Processing.
Xceed Zip Compression Library do support Asynchronous Processing; this feature can be enabled/disabled by setting the Zip Object’s property “BackgroundProcessing” to “True/False” :
objZip.BackgroundProcessing = True;
Imported from legacy forums. Posted by Alain [Xceed] (had 799 views)User (Old forums)MemberFebruary 9, 2011 at 3:28 pmPost count: 23064
Hi. I was googling for what may be a similar problem, and this exchange from a year and half ago came up. I have “inherited” a bit of code that we are converting to Exceed, and I get an exception on the call to CopyToFiles:
A first chance exception of type ‘Xceed.FileSystem.FileSystemIOException’ occurred in Xceed.FileSystem.dll
Additional information: The file item could not be opened for reading.
The file exists, has good permissions, etc. The only unusual thing is that (for some reason) the caller of my routine has a workflow that calls for the compression twice. The first CopyToFiles is successful, the second call results in the exception described above. I am wondering if i might be victim of the asynchronous
bug described previously.
My code looks like this:
CCompressHelper::CompressFileEx(BSTR inputFile, BSTR zipFile,
// following call generates exception the second time through:
diskFolder->CopyFilesTo(%oZipArchive, false,false,oDiskFile.Name );
} // CCompressHelper::CompressFileEx()
Now, there is no BackgroundProcessing property available on oZipArchive. So perhaps there is some other factor at work. Btw, I have also tried with the replaceExistingFiles argument set to true, with no change in behavior.
I would very much appreciate any insight or suggestion on this problem.
Software Scientist, Intergraph Corporation, Huntsville, AL
Imported from legacy forums. Posted by Chuck (had 159 views)User (Old forums)MemberFebruary 9, 2011 at 3:55 pmPost count: 23064
For some reason, the forum s/w truncated my code snippet. I repeat it here:
Xceed::Compression::CompressionLevel compressionLevel = ConvertCompressRateToXCeedCompressionLevel(compressRate);
System::String ^sZipFile = msclr::interop::marshal_as<System::String^>(zipFile);
System::String ^sInputFile = msclr::interop::marshal_as<System::String^>(inputFile);
sInputFile = sInputFile->Replace(
Xceed::FileSystem::AbstractFolder ^diskFolder = oDiskFile.ParentFolder;
oZipArchive.DefaultCompressionLevel = compressionLevel;
oZipArchive.DefaultCompressionMethod = Xceed::Compression::CompressionMethod::Deflated64;
Imported from legacy forums. Posted by Chuck (had 1238 views)
- You must be logged in to reply to this topic.