4

this might be a very general question - but I'm quite new to C#. Can you please explain this to me or give me a good link to an example or explanation.

I want to design a C# Winform application. The application has a main form, which collects user input when needed. Together with the UI a complex an long running calculation algorithm is developed. Start of calculation is triggered from a button on the main form. (CaculateClass.Start())

Question 1: At some point in time deep in the method call stack of the CaculateClass the CaculateClass detects that it needs further input from the user to continue the calculation.

In ancient C++ console application times one would have done something like this: cout << "Ask question"; cin >> answer;

How is this done in C# with winforms, to pass control to the UI from somewhere deep in the call stack, get input and return to the place where the calculation was interupted? Or has the CaculateClass to be designed somehow completely different?

Question 2 To avoid freezing of the UI a lot of articles recommend to put such long running calculations into another thread - e.g. by using BackgroundWorker()

If I let the CaculateClass.Start() be calculated by a BackgroundWorker -> How does the collecting user input work then?

Thanks for any help, CS

CSharper
  • 298
  • 2
  • 13

2 Answers2

4

How is this done in C# with winforms, to pass control to the UI from somewhere deep in the call stack, get input and return to the place where the calculation was interupted? Or has the CaculateClass to be designed somehow completely different?

It's probably not very language specific, but you'd want to decouple things. Get your inputs from a the form, act on it in a delegated class for example. Once your delegated class is ready and has results to show, you update your UI.

Question 2 To avoid freezing of the UI a lot of articles recommend to put such long running calculations into another thread - e.g. by using BackgroundWorker()

As for the responsiveness, yes a background thread would work fine there. Collecting input does not differ, you just pass the inputs to an object and that object calculates stuff for you. It a matter of a design choice to do that on the same thread or a different thread. The difference comes when posting the results back to the main thread. Since you should not (can not) change your user controls on another thread than the main thread, you would need to Invoke the results back to the Main thread. More on this topic can be found on MSDN.

A general remark on a general question :)

Try to keep the UI stuff as thin as possible. It's responsible to visualize things, and get user intput. Google for MVC (model view controller) - a well known GUI design pattern. Or have a look at MVVM (model view view model) - a somewhat more modern GUI design pattern. Both have a lot of best practices and ways to keep your design decoupled.

bas
  • 13,550
  • 20
  • 69
  • 146
3

You should have a look at Continuation Tasks: http://msdn.microsoft.com/en-us/library/ee372288.aspx

Tasks are the new programming paradigm for performing background work, they are preferred over BackgroundWorker.

aybe
  • 15,516
  • 9
  • 57
  • 105