Reputation: 13610
I could need a couple of tips as I feel that the way I do it isn't the "right" way and the default when creating a new GUI app in Visual Studio does not cut it for me.
What I'm doing is that I have a main class in my app that does all the work. It starts a couple of threads that collect and manage data, and i want it to "report" to the GUI form what its doing.
To hit that (above) off my main.cs (entry point of the app) inits the worker class (main class) and the form in two separate threads. Communication is then by delegates and is then not "flowing" as well as I hoped.
Would it be better if the main form gets inited in the main worker class so it owns the gui form? Instead of two seperate threads that needs some work to get to communicate with each other?
Upvotes: 2
Views: 112
Reputation: 1205
Here's one way of doing it. It might not be optimal for what you're doing, depends on the data you're passing around:
You could have the form as the startup object, and use BackgroundWorker
controls.
BackgroundWorker
has several events, all of which automatically run on the form thread, so you don't have to worry about delegates.
BackgroundWorker
supports reporting progress, and on the completion of the background thread you can return an object to the main thread in the completion event.
I'm pretty sure that you can't start a form on the same thread, if you do your method that inits the form will block until the form is closed (Although I could be wrong, since I haven't actually tried it)
Upvotes: 2