-3

I'm trying to figure out how to determine best practice when a void method returns for a program I'm working on. Basically the program has a call to a 3rd party grid to tell it to save the contents to an Excel sheet. The method to save the grid is a void method grid.SaveExcel(string filename, ...). I was thinking it would require the use of the await and async commands but have read in multiple places that this isn't best practice. I'm curious how you would go about doing this correctly as I'm a noob in terms of await, async, Lamda, Invoke, Action, Task, delegate stuff in C# and think I'm just confusing myself. I basically know how to open SQL connections, populate a grid, handle button event handlers, build basic classes, etc (very basic stuff).

I basically want to call the grid.SaveExcel method and then update a progress bar while I'm waiting for the saving of the grid to complete. Once it completes, I want to move on to the next few lines of code. Can someone help point me in the right direction and show me some code to attempt to accomplish this? Thanks in advance!

Dai
  • 141,631
  • 28
  • 261
  • 374
  • 1
    `grid.SaveExcel` is not a method in the standard .NET Framework. Where is it from? What is its definition? Is it a blocking (synchronous) method or a non-blocking (asynchronous) method? – Dai Mar 30 '17 at 17:26
  • I'm using the ComponentOne controls for WinForms. It is their C1FlexGrid (http://www.componentone.com/Studio/FlexGrid?platform=WinForms). I'm not sure if it is blocking or not. The saving takes anywhere from a few seconds up to a minute or so depending on how much data is loaded in the grid. I want to be able to manually increment a progress bar that I display while the saving is happening. – CSharpProgrammerNoob Mar 30 '17 at 17:38
  • 1
    If the method does not provide means for reporting progress, you will not be able to report progress. [That method](http://helpcentral.componentone.com/nethelp/c1flexgrid/C1.Win.C1FlexGrid.4~C1.Win.C1FlexGrid.C1FlexGridBase~SaveExcel.html) does not provide anything. You can run it on a separate thread to avoid blocking the UI, but you won't get progress. As for when it completes, it's when the execution hits the next instruction that you put after a call to that method. – GSerg Mar 30 '17 at 17:55

1 Answers1

0

You can invoke your function on a BackgroundWorker. https://msdn.microsoft.com/en-us/library/system.componentmodel.backgroundworker(v=vs.110).aspx

This class will then automatically raise an event on completion, as well as allow you to report progress during execution that will also raise events on your object invocation thread. Here's a run through of setting one up: https://www.dotnetperls.com/backgroundworker

All of this is assuming you do indeed need this process to be asynchronous.If you do not, you can simply invoke your save, and then immediately follow it with whatever post-save functionality you desire. If the save takes less than 200ms, you'd be better off just inlining it with the UI.

schulmaster
  • 413
  • 5
  • 16
  • Background is very old and obsolete approach, and sholud be used only if it's a legacy project on .Net 3.5 – VMAtm Mar 31 '17 at 13:03
  • 1
    I think "obsolete" is too strong a word. As this thread(pun) indicates, it is a contentious topic: http://stackoverflow.com/questions/12414601/async-await-vs-backgroundworker If you want to report progress, a BGW is very easy to implement as a beginner. Since the user-state is an object, you can literally send anything back to the invocation thread as often as you want, and the means of doing so are built in to the object. I'm not saying its better than async/await, but the difference is less stark than String.Format against interpolation, which is cleaner in almost every case. – schulmaster Mar 31 '17 at 16:08
  • New approach to report a progress is, well, `Progess` class. BGW can easily be replaced with `TPL` and/or `async/await` – VMAtm Mar 31 '17 at 16:18
  • And BGW is **explicitly** labeled in .Net 4.5: http://stackoverflow.com/a/16366418/213550 – VMAtm Mar 31 '17 at 16:19
  • 1
    @VMAtm The [very first comment](http://stackoverflow.com/questions/12414601/async-await-vs-backgroundworker/16366418#comment23466751_16366418) under that answer corrects this statement. – GSerg Mar 31 '17 at 18:26
  • Ok, not officially, yet by famous names in industry – VMAtm Mar 31 '17 at 18:28