I'm putting together a class library and one of the functions within it is to update a local database with information obtained from a web service.
I'd like to have the option to show the progress of this so have also put a small form in the library with a progress bar on it.
Everything works but I'd like to make the progress bar more reliable and smoother. It's the same old problem of tying up the UI thread with an intensive operation so the UI updates aren't done.
With a windows form application I'd have gone straight for a background worker. However with a class library this if different and I'm not sure how to approach this/whether it will work.
Windows Form:
Form Loads
Async Process started on worker
worker reports progress to form event
form updates UI
worker continues
etc.
Worker reports complete in form event
Form updates UI
The key point here is the form is loaded and listening for events throughout this.
Class library:
Create new object
Call update sub on object
update sub creates instance of progress bar form and starts async worker
worker reports progress to object which updates progress form
But:
Update sub has completed by this point so the rest of the procedures in the code that instantiated the object will have ran by this point and the object may have been set to nothing. Therefore there is nothing to report the progress to.
Does that make sense? I've not tested this and there could be some stuff going on int the .Net underbelly that ensure the object is kept alive until the worker has done but this doesn't feel right.
What I effectively want to do is tell the code to stop what it is doing but keep updating the UI as appropriate until the worker has finished.
Hope that explains the scenario.
I guess to add a little more, the code will be initially called from within a COM interop component loaded in Excel.
So:
Excel Loads
Excel calls load events on addin
Addin references library
Load events instaniate object in library and call update
Any suggestions really apppreciated.
Mark
p.s. The workaround to this is to use 1 thread and form.refresh with every update - I suspect this slows things down quite a bit though.
I'd like to have the option to show the progress of this so have also put a small form in the library with a progress bar on it.
Everything works but I'd like to make the progress bar more reliable and smoother. It's the same old problem of tying up the UI thread with an intensive operation so the UI updates aren't done.
With a windows form application I'd have gone straight for a background worker. However with a class library this if different and I'm not sure how to approach this/whether it will work.
Windows Form:
Form Loads
Async Process started on worker
worker reports progress to form event
form updates UI
worker continues
etc.
Worker reports complete in form event
Form updates UI
The key point here is the form is loaded and listening for events throughout this.
Class library:
Create new object
Call update sub on object
update sub creates instance of progress bar form and starts async worker
worker reports progress to object which updates progress form
But:
Update sub has completed by this point so the rest of the procedures in the code that instantiated the object will have ran by this point and the object may have been set to nothing. Therefore there is nothing to report the progress to.
Does that make sense? I've not tested this and there could be some stuff going on int the .Net underbelly that ensure the object is kept alive until the worker has done but this doesn't feel right.
What I effectively want to do is tell the code to stop what it is doing but keep updating the UI as appropriate until the worker has finished.
Hope that explains the scenario.
I guess to add a little more, the code will be initially called from within a COM interop component loaded in Excel.
So:
Excel Loads
Excel calls load events on addin
Addin references library
Load events instaniate object in library and call update
Any suggestions really apppreciated.
Mark
p.s. The workaround to this is to use 1 thread and form.refresh with every update - I suspect this slows things down quite a bit though.