0

I have a multi-step BackgroundWorker process. I use a marquee progress bar because several of these steps are run on a iSeries server so there isn't any good way to determine a percentage. What I am envisioning is a label with updates after every step. How would you recommend updating a label on a winform to reflect each step?

Figured I would add a bit more. I call some CL and RPG programs via a stored procedure on an iSeries (or IBM i or AS/400 or a midrange computer running OS/400... er... i5/OS (damn you IBM for not keeping the same name year-to-year)).

Anyway I have to wait until that step is fully complete before I can continue on the winform side. I was thinking of sending feedback to the user giving the major steps.

  1. Dumping data to iSeries
  2. Running month-end
  3. Creating reports
  4. Uploading final results

I probably should have given this in the beginning. Sorry about that. I try to keep my questions general enough for others to make use of later rather than my specific task.

Mike Wills
  • 20,959
  • 28
  • 93
  • 149

2 Answers2

1

This is one of the points of a background worker in essence. Use a ProgressBar and just determine how far along the progress is, according to your algorithm.

(As has been mentioned, if they're 10% through, send 10, if they're 50% through, send 50)

Using a BackgroundWorker bgWrk

Add the following event:

bgWrk.ProgressChanged += new System.ComponentModel.ProgressChangedEventHandler(bgWrk_ProgressChanged);
// Note: This method is invoked on the UI thread

void bgWrk_ProgressChanged(object sender, System.ComponentModel.ProgressChangedEventArgs e)
{
    // Add progress to whatever UI element needs updating. The below simply uses a progress bar.
    prog.Value = e.ProgressPercentage;
}

After each major step that you think deserves a user updates do the following:

bgWrk.ReportProgress(intValue);

A couple of notes:

  • You can pass an Object as well in the ReportProgress() method, so you would be able to update a label with a string object etc, however a progress bar is still the universal symbol of "hold on, i'm doing something"

  • If you have any indeterminate polling, and you are using a ProgressBar, try use it as an Indeterminate ProgressBar, or a spinner or such. WPF has a built in property to make a progress bar indeterminate which is useful.

Kyle Rosendo
  • 25,001
  • 7
  • 80
  • 118
  • one thing you left out Rozendo: the ProgressChanged event - is that method invoked on the UI thread or on the background thread? – Cheeso Mar 16 '10 at 14:17
  • It will invoke on the UI thread. It was designed to be able to be used with ProgressBars in particular. This is why the EventArgs provide a percentage to be able to access this functionality. – Kyle Rosendo Mar 16 '10 at 14:17
0

How many steps is there? If there's 10 steps, simply use 10% step up marker for the end of each step that completed successfully.

t0mm13b
  • 34,087
  • 8
  • 78
  • 110
  • The steps on the iSeries are over 50% of the steps of which I can't communicate back to C#. I guess I could just update by percentage anyway. – Mike Wills Mar 16 '10 at 14:10
  • oh....iSeries as in mainframe? or AIX boxes? I will edit this answer accordingly... – t0mm13b Mar 16 '10 at 14:13
  • iSeries as in IBM i or AS/400 or a midrange computer. It runs OS/400 and the called logic is in CL and RPG. I have to call it via a stored procedure and I have to wait until it completed successfully before I can move on to the next step. – Mike Wills Mar 16 '10 at 14:16
  • Ahhh...AS/400...Command Language (CL) and how are you connecting to it? are you talking to a TCP/IP port...Is the CL script sending a status back to the TCP/IP port? – t0mm13b Mar 16 '10 at 14:17
  • Through IBM's ADO.NET provider. It appears to be an optimized ODBC connection. – Mike Wills Mar 16 '10 at 14:23
  • @Mike: it might help to show a section of the CL script and the ado.net connection side of it...in terms of code... – t0mm13b Mar 16 '10 at 14:35