0

I have an grid application that allows users to export the grid to Excel and display it. The application gives the Excel file a name that is related to the grid. If the user makes some changes and does a second export while the file from the first export is still open, it causes a System.IO.IOException, which says, "The process cannot access the file 'xyz.xls' because it is being used by another process."

Right now the user gets a message to close the original file and to try exporting again. There is no simple way to close the file from my application that I know of. I am thinking about changing the application so that the file has a unique name (using a guid or something) every time it is exported so that the exception does not occur. However, that would mean the user would possibly have multiple files open.

Which is worse--making the user close a file before they can export a second time or having multiple similar files open?

Update

Exporting to Excel is an option. Some users never export. Some users may export 10 or more times in one session. Users typically export to manipulate data in Excel or to format the data how they want it and then print.

|improve this question
  • Usually, it makes sense to keep the question open for at least a couple of hours before accepting an answer even if the first one seems like the best one. – dnbrv Feb 23 '12 at 19:15
  • @dnbrv thanks for the advice. I did wait about an hour and a half. I will try to be more patient next time. – Daniel Feb 23 '12 at 19:24
4

If you explained a bit more about the use case for your app, we might be able to give a more constructive answer... for instance, how does exporting fit into the user workflow? Is it a universal step in the process, or is it an option? How often is the user likely to export multiple times in the same session? etc.

However, given what you have described, I've got to ask why you're not allowing the user to specify a file name for the exported file (and why you're making the assumption that a user who exports the file to Excel even wants the file to open in Excel immediately). More typically, 'Export' functionality is just another type of file save option. So, for instance, OmniGraffle's export menu looks like this:

Omnigraffle Export

... which provides many more options for the power user without slowing down common use cases (because the defaults make sense, including a filename that matches the native file name... if you try to export again using the same name, you get a "want to replace the existing file?" dialog window).

Edit: Given your further scenario description, I would strongly recommend that a dialog box is the way to go. If directly opening the file in Excel after export is important to some users, I would include a checkbox on the dialog saying something like "Open in Excel after export" or something like that. Remembering the user's last-used settings will help in not making this too much of a roadblock. Of course, as always, your milage may vary -- so test, test, test.

|improve this answer
  • I updated the question to explain the use case more. I like your suggestion of the dialog box, but it does make the user have to go through more steps--at least one extra click. Definitely worth an up vote. – Daniel Feb 23 '12 at 17:49
  • 1
    FWIW, I do a lot of work in Fireworks, which has a frequently used export function. Some days I export hundreds of times a day. It's a mix of overwriting existing files or saving out new variants. There is a similar dialog to the one above. I don't mind this step because I can plow right through it with the enter key when I am overwriting. If I need to change the filename, it's an easy tweak before proceeding. Not sure how relevant that is to the use case where the file is already open, however. – peteorpeter Feb 23 '12 at 18:08

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.