views:

102

answers:

3

This seems like it would be pretty common task, but I'm not having any luck searching for an answer.

I have a WPF/C# application that relies heavily on a dll for database routines. I would like the dll to update some GUI elements, i.e. a progress bar.

So far, it seems that the answer lies somewhere in System.ComponentModel and creating a backgroundworker. But that's as far as I can get.

Can someone please offer suggestions on how to accomplish this task? Links, sample code, encouraging words appreciated!

Many thanks,

Jerry

A: 

A BackgroundWorker would work, as would a Task object (I prefer Task, personally). My blog has an example of both of these doing background work, with full support for cancellation and incremental progress. You may not need this level of complexity (e.g., cancellation).

Stephen Cleary
+3  A: 

Your best bet is to set it up so that the UI passes in a callback function when calling into the database DLL. The database DLL calls that callback "periodically", and the callback implemented in the UI then updates the UI elements.

It would be best not to let your database DLL muck around with your UI. For one thing, it would make the DLL very dependent upon the specifics of your UI, to the point that the DLL would not really be usable by any other exe.

dthorpe
That was my biggest concern, the reusability of the dll in later applications. I was hoping to make whatever I did generic enough. But I like your suggesstion of a callback function, which I will explore.
Jerry Davis
+1  A: 

It's a little hard to tell exactly how your code works now, and I think the answer depends on whether or not your current implementation is blocking the UI (i.e., by making a synchronous call to your DB DLL).

Now, if your call to the DLL is a synchronous one and it's blocking the UI then, yes, you might want to consider using a BackgroundWorker to do that work and allow your main UI thread to avoid hanging. You can refer to http://stackoverflow.com/questions/1259949/how-to-implement-progress-bar-and-backgroundworker-for-database-calls-c for some answers.

But you still need some mechanism for knowing the progress of your DB call, and it doesn't sound like the DLL exposes anything like that yet.

Just reading between the lines of your question, it sounds like you have some ability to modify the DLL. If so, then you should try to use a pattern that preserves decoupling between the DLL and your UI app when providing progress information. Your UI code should really be responible for updating itself based on some data that the DLL can provide in a loosely coupled way. I would suggest using either:

  • A subscription model by listening on an event published by some class in the DLL; or
  • A polling model to actively monitor some data object implemented in the DLL on a periodic basis (e.g., during a Timer Tick handler).

Either way, you want to avoid tightly coupling the two layers together by coding the DLL to have intimate knowledge of your UI layer. Both of the aforementioned possibilities should allow you to keep your UI updating code on the main UI thread of your app executable in most circumstances, which is important if you want to avoid multithreading issues.

Matt
You are right, I authored the dll. Your suggestion is helpful as well. Thanks for the reply!
Jerry Davis