Re: Load secondary form in backgroundworker thread

Now that I think about it, forget the event (it could block the ui thread -
bad). Just Enable the form2 button when it is ready as the last line in
your form2 fill method.

--
William Stacey [C# MVP]



"William Stacey [C# MVP]" <william.stacey@xxxxxxxxx> wrote in message
news:OeaaKyGuHHA.1496@xxxxxxxxxxxxxxxxxxxxxxx
| As others have said, do the time consuming parts (i.e. db loads) on a
worker
| thread in the background. When it is done, create form2 and set the
| controls, then set a reset event. The form2 open button on form1 will
wait
| on this event, so if user tries to open form2 before load is done, it will
| wait. If reset is set, just Show form.
|
| --
| William Stacey [C# MVP]
|
|
| "RvGrah" <rvgrahamsevatenein@xxxxxxxxxxxxx> wrote in message
| news:1182914203.214073.179960@xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
|| What I mean by that is that I want the second form "pre-loaded" in
|| memory before the user gets around to needing it, so that when he does
|| click the button to show this second form, it will appear almost
|| instantly. I don't want him to notice in the sense that I want him to
|| be able to merrilly work away in form1 without noticing any bogging
|| down of the machine while the form is pre-loading in the background. I
|| show a splash screen during the 3-4 seconds it takes to show the first
|| form, but I don't want to have to show an hourglass for the current 3
|| seconds or so it takes the second form to be visible if I can get away
|| from it.
||
|| The second form will almost always be called upon sooner or later
|| while the person has my app open, and system resources are not an
|| issue, snappy-seeming code speed is an issue.
||
|| Thanks, Bob
||
||
|| On Jun 26, 11:46 am, "Peter Duniho" <NpOeStPe...@xxxxxxxxxxxxxxxx>
|| wrote:
|| > On Tue, 26 Jun 2007 08:18:12 -0700, RvGrah
|| >
|| > <rvgrahamsevaten...@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
||
||
|
|


.