Using the ProgressBar Control

As I mention elsewhere in the book (any number of times), it's not how fast your application runs that makes a user happy, but how fast it seems to run. The ProgressBar and other real-time feedback controls can help you build the appearance of good performance into your application. As I'll discuss later in the sections on handling ADO.NET asynchronous operations, you can simply use the UI thread to increment a ProgressBar controlbut only if it's not busy running an ADO.NET method or other blocking operation.

Actually, if all you want is an animated control and you don't care if it actually reflects the real "progress" of an operation, then simply set the ProgressBar control's Style property to "Marquee", as shown in Figure 7.24. In this case, the moving bars simply move from one end of the ProgressBar to the other and repeat. I'll let you experiment with the numerous mechanisms to increment the other styles.

Figure 7.24. The three ProgressBar Style property settings in action.

If the operation you're executing while entertaining the user with the ProgressBar is going to take more than 10 seconds or so, you should consider how to let the user know how much time the operation is really going to take. Unfortunately, as you well know, execution time is not always easy to determine in advance. It's like trying to predict when the ocean levels will reach the steps of the Capitol building. The length in time of computer operations is determined by the performance of the system, the system workload at the time, and, when working with SQL Server, how much traffic is on the Net, the server workload, and a dozen other factors outside of your controllike having police setting up barricades around your house. Your task might not ever finish due to one of these unforeseen factors or simply because you executed a query that can't be completed before Microsoft stops supporting your version of Visual Basic.

When I want to keep the user from rebooting the system while a long operation is executing, I take one of the following approaches:

• "Fake" the progress. That is, I start a progress bar and set the upper limit to a very high number. I then increment the value every few seconds and increment the value halfway up the scale. That way (in theory), the progress bar never really reaches the end. What it does do (which is bad) is appear to stall several seconds into the run. This is what Access did at one timebut it used a very long progress bar. This approach still causes users to close the application after awhile, as they think it's stuck. That's exactly opposite of what we want.

• "Guess" the endpoint. When I run any query, I have a rough idea of how long it's going to take. This value is based on history, experience, conditions I do control, and other deterministic factors. I then set this value plus a fudge factor as the Maximum property setting in the ProgressBar control. If I do reach this Maximum value, I know (suspect) something went wrong, and I give the user the opportunity to bail or keep waiting. Perhaps the user knows something I don't. The next time I run the same routine, I know that in the last run, it took quite a bit longer (or shorter), so I set the Maximum property to reflect current reality.

• "Never stop". An approach used by Microsoft Office is to slowly increment the ProgressBar but, when it reaches the Maximum value, restart it. This is not much better than the Marquee style IMHO.