K
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
(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