tags:

views:

35

answers:

2

This app that I am doing uses a class library (if I dare call it that) to do the bulk of the work: 2 main methods in there (DoWork and UndoWork) use the other classes to achieve thier goal. Now that that works, I want to get out of the Console test enviroment and do a GUI.

How would I get the status of say, the DoWork() method to update a progress bar? Should I multilate the class library (which currently works with the Console and Windows.Forms) to update? The problem with that is that I would surely have to make the class library use Window.Forms which will mess up the console testing apps (And there are lots of them - I tested all the way through, and then all together).

Could you suggest some ideas, or places I can read up about ideas (the whole point of writing this this program is to learn, afer all)?

Oh, by the way, suggestions like "foresight" or "planning" probably won't help here...(now, anywyay!) - But certainly will in future projects!

A: 

You should make the method take an additional parameter that implements an interface or delegate to receive progress reports.
You should then make a no-op implementation of the interface for console apps, and an implementation that updates a ProgressBar control for WinForms.

SLaks
+1  A: 

Instead of hacking up DoWork() to actually draw the status update, simply modify it to provide progress updates to a delegate that you (optionally) provide while initializing DoWork().

This way, you can provide a delegate that simply prints the status update when you're a console app, and you can provide one that causes the progress bar to be updated in the GUI app.

sblom
+1 - I think using a delegate coupled with an event would be the best way to handle this in a robust manner
Wayne