The Design of Software (CLOSED)

A public forum for discussing the design of software, from the user interface to the code architecture. Now closed.

The "Design of Software" discussion group has been merged with the main Joel on Software discussion group.

The archives will remain online indefinitely.

How to handle progress updates?

I have a GUI app which basically goes through a list of files and performs some operations on them.

The GUI makes it possible to select a directory. The dir is then passed to code which goes through the files.

The logic is contained in a class. This way, I thought, I keep the logic and presentation seperate. The problem I'm having is that I want to show a progress bar. How do I let the GUI know about the progress of the class in a flexible way?
Guyon Morée Send private email
Friday, April 01, 2005
I think I'm asking for a pattern, right?

Guyon Morée Send private email
Friday, April 01, 2005
You have several options:

a) process the files in a worker thread, the UI thread can display the progress on its own

b) process the files in idle loop

c) process the files in a "simple" loop and periodically call the method (provided by the framework) to process events
Pythonic Send private email
Friday, April 01, 2005
excuse me my stupidity, but I don't get any of these suggestions which make me think that I didn't explain it good enough.

pseudo code:

 path = getPathFromTextBox() // get path
 result = ProcessingObject.Process(path) // process path/*.*

Now I have a progressbar on my GUI, which should update with every file processed by the ProcessingObject. How do I do this without coupling the object with the gui?
Guyon Morée Send private email
Friday, April 01, 2005
Create an event in the progress object and subscribe to it from the GUI.
Cowboy coder
Friday, April 01, 2005
I think I had an analogous problem writing a server. The server had no GUI of its own with which to display error messages. Since the server was meant to be used in conjunction with a host app, I defined an interface (pseudocode follows)
  interface IMyStupidServerCallbacks
      void DisplayError(string s);
      void DisplayProgress(string s);
      // and so forth

I forced the host app to support this interface so the server could forward messages to the APP for display. The server didn't care how (or whether) the host app displayed the information.

Maybe you can do the same thing with your back end: define an interface that the host app must support. Then the worker object that processes files can periodically call back through the interface to pass along the percent-complete to the host app.
John Foxx
Friday, April 01, 2005
> define an interface that the host app must support

or better: an interface that the host app can optionally support.  Then the host app passes a null reference if it is not interested in progress notifications (e.g. if it is a batch process rather than a GUI).
Friday, April 01, 2005
I do this type of thing in Surfulater using FastDelegate

For me FastDelegate is one of those rare almost life changing bits of code we are lucky enough to come across.

Here is a code snippet:

using namespace fastdelegate;
typedef FastDelegate1< const char* > ProgressDelegate;

        ProgressDelegate ItemProgressDelegate( this, &CMainFrame::StepStatusBar_ProgressControl );

result = ProcessingObject.Process(path, ItemProgressDelegate);

Then in your ProcessingObject you call ItemProgressDelegate() which in turn calls CMainFrame::StepStatusBar_ProgressControl() without having any clue that it is doing so.

Incredibly elegant and totally hides the two bits of code from each other. Highly recommended. :)

You can see this in progress ;-) when saving info from your browser, sending e-mail etc. in Surfulater

If you need further help let me know.
Neville Franks Send private email
Saturday, April 02, 2005

This topic is archived. No further replies will be accepted.

Other recent topics Other recent topics
Powered by FogBugz