Setup app, with single progress dialog.
-
I have a simple C# application that performs some setup tasks and exits, once done, with no user notification. I would like to display a progress dialog showing status. Currently my setup code is in the Run method of the program instance. I could create two forms. Form A would be not visible and would perform setup tasks. Form A would create Form B that displays progress. Form A could manipulate Form B controls. This I could have done, but seems unnecessary and not proper. What I was trying to accomplish was including the setup code in the Run function of the program instance. And creating a single progress dialog there. But then I'm missing a message pump for forms? (is that correct wording). Form would not process paint events I'm guessing. Am I over-thinking this? I would like to accomplish having a thread (maybe original app thread) processing setup tasks, and a separate thread or message pump for form? To accomplish this, I think would help me in understanding more about threading and app processing. Thanks for your help!
-
I have a simple C# application that performs some setup tasks and exits, once done, with no user notification. I would like to display a progress dialog showing status. Currently my setup code is in the Run method of the program instance. I could create two forms. Form A would be not visible and would perform setup tasks. Form A would create Form B that displays progress. Form A could manipulate Form B controls. This I could have done, but seems unnecessary and not proper. What I was trying to accomplish was including the setup code in the Run function of the program instance. And creating a single progress dialog there. But then I'm missing a message pump for forms? (is that correct wording). Form would not process paint events I'm guessing. Am I over-thinking this? I would like to accomplish having a thread (maybe original app thread) processing setup tasks, and a separate thread or message pump for form? To accomplish this, I think would help me in understanding more about threading and app processing. Thanks for your help!
David Hovey wrote:
I could create two forms.
Asynchronous programming might be an answer to your problem.[^]
David Hovey wrote:
Am I over-thinking this?
Possibly.
David Hovey wrote:
To accomplish this, I think would help me in understanding more about threading and app processing.
That though is true.
My signature "sucks" today
-
I have a simple C# application that performs some setup tasks and exits, once done, with no user notification. I would like to display a progress dialog showing status. Currently my setup code is in the Run method of the program instance. I could create two forms. Form A would be not visible and would perform setup tasks. Form A would create Form B that displays progress. Form A could manipulate Form B controls. This I could have done, but seems unnecessary and not proper. What I was trying to accomplish was including the setup code in the Run function of the program instance. And creating a single progress dialog there. But then I'm missing a message pump for forms? (is that correct wording). Form would not process paint events I'm guessing. Am I over-thinking this? I would like to accomplish having a thread (maybe original app thread) processing setup tasks, and a separate thread or message pump for form? To accomplish this, I think would help me in understanding more about threading and app processing. Thanks for your help!
Use a
BackgroundWorkerto do the long running tasks and useReportProgressto update theProgressBar. Alternatively, use my ProgressWorker[^] which I made for exactly this purpose.Dave
If this helped, please vote & accept answer!
Binging is like googling, it just feels dirtier. (Pete O'Hanlon)
BTW, in software, hope and pray is not a viable strategy. (Luc Pattyn) -
I have a simple C# application that performs some setup tasks and exits, once done, with no user notification. I would like to display a progress dialog showing status. Currently my setup code is in the Run method of the program instance. I could create two forms. Form A would be not visible and would perform setup tasks. Form A would create Form B that displays progress. Form A could manipulate Form B controls. This I could have done, but seems unnecessary and not proper. What I was trying to accomplish was including the setup code in the Run function of the program instance. And creating a single progress dialog there. But then I'm missing a message pump for forms? (is that correct wording). Form would not process paint events I'm guessing. Am I over-thinking this? I would like to accomplish having a thread (maybe original app thread) processing setup tasks, and a separate thread or message pump for form? To accomplish this, I think would help me in understanding more about threading and app processing. Thanks for your help!
David Hovey wrote:
Am I over-thinking this?
Yes. You don't need two forms or to use the Run method. Have one form the displays the progress indicator and, as Davey, suggests use a Background worker to complete the tasks. Start the background operation from the FormLoad event.
I know the language. I've read a book. - _Madmatt