Threads and WinForms

[Ken Allen]

I am relatively new to .Net, but I have been programming for some time
(longer than I want to admit and in more languages than I want to think
about).

I have been reading a lot about the use of threads and invoke methods to
permit multiple threads to update the same user inerface. I understand all
of the points that are made and why this is generally a good thing, but I
simply cannot get my head around some common patterns that I program and how
they would be implemented in this approach.

Consider the example of a very small application that contains three (3)
forms: a control form; a work-in-progress (WIP) form; and a results form.
The control form is displayed when the applicaiton launches (although it may
be bypassed based on command line entries) and is used to collect
information from the user concerning the processing to be performed. In some
cases these are simple parameters to a single process, but in others the
control form may permit one of several specific processes to be performed.
When the user elects to initiate a process (and all parameters have been
validated), the control form is usually closed/hidden, a modeless WIP form
is displayed (typically just telling the user to be patient), and the
process is initiated. When the process completes, the WIP form is closed and
a results form is displayed. When the results form is closed by the user,
then the application typically exits.

Because of the simplicity of this approach, developers tend to use define
the control and results forms as modal, and write the entire process as a
single thread. This works, but it means that the modeless WIP form does not
get repainted properly when the actually processing takes a long time and
the user switches applications while waiting. In some cases the application
does not exit when the results form is dismissed by the user, but rather the
control form is displayed again, either with standard or the last defined
settings enabled.

In order to take advantage of threads in this case, I suspect that I would
have to modify (or develop) the entire application using only modeless
forms, correct?

From my C++/MFC days I can (vaguely) remember how to make some calls to
define a specific dialog as the default dialog for the application, and how
to change this default dialog on the fly, such that the applicaiton does not
terminate until that default dialog is dismissed. I cannot find any strong
references on how to achieve this in C#/.Net -- is this an easy process? I
want to acheive the same thing that occurs when an application is specified
to start from the Main() within a form, but I want to start from my own
Main() and specify that form at run time.

So I shall need to defined a thread method that I can launch from the GO
button on the control form. Before the thread is launched I should
close/hide my control form and cause the WIP form to be displayed. I should
pass a reference to the WIP form into the thread start, which will permit
the process to not only update the WIP form with progress information (using
invoke methods, of course), but also to close the WIP form (again using an
invoke method) when the process is complete. The process could then cause
the results form to be displayed modeless.

Now is the case where sometimes I want the application to treat the results
form as the startup form, so that when the user dismisses it the program
will terminate automatically.

If the control form is closed as part of the pressing of the GO button, the
code for which displays the WIP form and starts the process thread, what
keeps the application from terminating? Obviously the control form cannot be
set as the startup form or closing it in the GO button would terminate the
application; on the other hand, if I want the dismissal of the results form
to cause the control form to be displayed again, that is another issue.

I cannot see the proper way to use the threading and invoke methods to solve
this problem. If someone can point out how simple this is to achieve, I
would appreciate it.

-ken

 

[Justin Rogers]

I think for the concepts of not exiting, you are going to want to use an
ApplicationContext.

http://weblogs.asp.net/justin_rogers/archive/2004/04/11/111162.aspx

Follow the link to the Wizard Framework as well for an example of some code that
uses
the ApplicationContext to control when the app should actually exit.

 

[Ken Allen]

The following snippet is from the referenced web page. First, the link to
the "wizard framework" does not work. Second, I can find almost no
assistance on how one would program using the ApplicationContext, especially
how to use this approach when no MainForm is specified.

You do not explain how tp "hook the Closing or Closed events of all my forms
to make sure that I'm always executing code", or what this actually means. I
presume that you expect the first form to be displayed before the call to
Application.Run().

Nor do you explain how you "trap the Application.Idle event from within your
ApplicationContext".

I can see how some of this might be used, but I cannot complete the picture.

-ken

<<Now we are ready for the ApplicationContext. The ApplicationContext is
best used for things like my wizard framework where the component itself
knows how to shut things down, but the component isn't a Form. Creating
timers and hooking idle are global ways of handling things, while the
ApplicationContext is more modular and object oriented. For purposes of
stringing Forms together, I would recommend that your ApplicatonContext not
even bother setting the MainForm property, rather I'd make sure to hook the
Closing or Closed events of all my forms to make sure that I'm always
executing code. You can still trap the Application.Idle event from within
your ApplicationContext as well and use that.>>