3

I have a windows application that reads from a database and populates multiple Listview containers depending on what items the user selects. Some of the data in a particular Listview is right-clickable with a MenuItem option to ‘Write Data to Excel’. This may take around 10 minutes to complete.

I have the Excel Interop portion written in stand-alone code or can I incorporate it into the application project. The Excel Interop app takes only 1 parameter to do its thing.

My question is… should I incorporate it into the Windows App and use multithreading or run it as a standalone app (which seems more efficient), which is called from the Windows App? And what is a good way of doing that where the Windows app starts the process and then can forget about it.

BenMorel
  • 34,448
  • 50
  • 182
  • 322
Chris
  • 118
  • 1
  • 9
  • are you looking for a windows service? – JustCode Jun 26 '13 at 13:05
  • 2
    It will be far more easier to give feedback to the user (progress bar) within the application itself, than making several process talk together. Moreover, I can't see why a worker thread would be less efficient than a console application. – Steve B Jun 26 '13 at 13:05
  • see [Multithreading vs. Multi-Instancing - Which to choose?](http://stackoverflow.com/q/9473212/201088) – Eren Ersönmez Jun 26 '13 at 13:05
  • Thanks for the replies. I really don't need any feedback to the winapp. The excel sheet will open and ask to be saved-as when finished. I just want to kick it off and forget about it, while the winapp continues as normal. – Chris Jun 26 '13 at 13:14
  • As a side point - I've done lots of excel interop to generate reports from databases, which seems similar to what you're doing. There are libraries that can write native excel xls or xlsx files, and can do it in seconds instead of minutes. xlsgen is so far my favorite since it is the most complete. – antiduh Jun 26 '13 at 13:27
  • Wow, thanks antiduh. I'm going to look into that. – Chris Jun 26 '13 at 13:43
  • You really should, besides the performance gains from not using Excel Interop that @antiduh mentions, Excel Interop requires the person using it to have Excel installed. Why is this a bad thing? You might reasonably ask. The answer is because it is hilariously poorly implemented, and you need to spend months trying to find the correct library. Some of your customers still use Office 97 (Excel 5)? Good luck with that. Someone using an international (ie other than US-EN) version of Excel? Good luck with that. Excel Interop is rubbish. – Mikkel Løkke Sep 20 '14 at 00:27

3 Answers3

3

I think that the answer for this one is answered by the question : "What should happen if the user closes the main application during those 10 minutes ?"

If the file should still be wrote, then a standalone application is perfect, cause your threads won't survive.

If the file creation should be interrupted, then I see no reason not to use multithreading, as it seems simpler by default, in particular debugging this part of the code is way easier if it's in the same application.

C4stor
  • 8,355
  • 6
  • 29
  • 47
  • Good point, the writing to the Excel file should continue if the winapp is closed. Now I'm looking for a solid way of doing this and of course not waiting for the process to complete - halting up my windows app. – Chris Jun 26 '13 at 13:24
  • `Process process= new Process(); string arguments = "whatever" process.StartInfo.Arguments = arguments; process.StartInfo.FileName = "myexe.exe" process.Start();` ? – C4stor Jun 26 '13 at 13:27
0

I would recommend for the below flow:

  1. We can create our own queue which will be either maintained in database or file system.
  2. Then we can write a scheduler which will fetch all the unprocessed request and with the respect to response mark appropriate status of queued item.

Now You application can just call the queuing process and move forward from there.

Rohit Singh
  • 106
  • 2
0

Use another thread to write it.

mjb
  • 7,649
  • 8
  • 44
  • 60