Re: Load secondary form in backgroundworker thread

On Tue, 26 Jun 2007 08:18:12 -0700, RvGrah <rvgrahamsevatenein@xxxxxxxxxxxxx> wrote:

I haven't had time to digest this yet but I can see you know a bit
about it. At first glance I think I'll most likely go with the route
of using the backgroundworker to do the database load. The part I'm
still working on (in my head) is the fact that I want the user to not
be aware of any of this going on in the background unless he's
watching a CPU meter or his hard drive led.

Well, what do you mean by "not be aware of any of this"?

You can certainly silently start up the background thread without providing any feedback to the user. They won't have any idea that anything's happened until the initialization is done and you show the form. But are you sure that's really what you want?

Generally speaking, the #1 rule in user interfaces is that when the user does something, there should be feedback. If they click on a button and _nothing_ happens, the most likely thing that the user will do is to click on the button again. Now, you can easily deal with that case, ignoring the subsequent clicks once you've seen the first one. But that does nothing to ease the user's frustration.

In most cases, you will want to provide the user with some feedback that you received their interaction and are doing something about it. You said originally that you don't want to show the form until the initialization is done. It's fine if you want to design your UI like that, but you should put some sort of feedback somewhere else (perhaps in the original form). With the BackgroundWorker class, you can also subscribe to the ProgressChanged event, and then in the initialization code call the ReportProgress() method to cause that event to be raised. In the ProgressChanged event, you can update the appropriate user feedback to indicate progress of the initialization.

If you are going to do a lengthy operation in the background, without providing any feedback to the user at all, you should have a _very_ good reason for doing so. Consider such a design very carefully, because in nearly all cases it's wrong. I would even go so far to say that if the lengthy operation is a direct consequence of an explicit user action, it's _always_ wrong to not provide feedback.

Pete
.

Loading