Thanks for your help on the issue Mike, much appreciated!  Having the CancelExport work inside the error event will also be a nice addition in the future.

Yes, you are correct on both counts. Sorry... I guess I got a little over-enthusiastic about finding a workaround. :)

We are still going to fix it so that the CancelAsynchronousExport works when called inside of the AsynchronousExportError event. But you really don't need it, now.

After some more testing with a grid containing 10K records, I've found that the workbook must be saved and the file stream closed in the ExportEnded event instead.  In your previous sample, the wb.Save gets hit before the ExportAsync has completed.

This is a great solution that I'll be adopting, thanks Mike!  One minor tidbit:  there should be a fileStream.Close after the wb.Save call.  If you try to open the file while your form with the exporter is still open, the export file is still locked.

Hi,

I looked into this some more and I found a much better workaround.

The way you are currently doing this, there is a big potential for a lot of wasted effort. By the time the export operation fails, most of the work is already done, and all of that work was unnecessary since it failed. It makes a lot more sense to create the file stream up front and make sure it's not locked before you start exporting.

So you could change your code like this:

                //ultraGridExcelExporter1.ExportAsync(ultraGrid1, ofd.FileName);
                FileStream fileStream = new FileStream(ofd.FileName, FileMode.CreateNew);
                Workbook wb = new Workbook(WorkbookFormat.Excel2007);
                ultraGridExcelExporter1.ExportAsync(ultraGrid1, wb);
                wb.Save(fileStream);

Put a try... catch around the creation of the FileStream and if an expceiotn exception is raised, you will know that the file is in use and can handle it without ever starting the export and wasting all that processing.