1,105,169 Community Members

C# WPF Application to configure server

Member Avatar
SCass2010
Junior Poster in Training
93 posts since Mar 2010
Reputation Points: 0 [?]
Q&As Helped to Solve: 0 [?]
Skill Endorsements: 0 [?]
 
0
 

Hi everyone,

Currently for a university project I am building a server that can send notifications to a mobile device. Part of the project involves building a front end where I can configure everything for the server - updates to send, rules and so on. On the front end I have a button to Start or Stop the server - "Start" begins a BackgroundWorker that creates and starts the server (the server is a .dll kept in a separate project, the server is a private variable in my MainWindowViewModel).

Is this the correct way to handle this? If I start the server without the BackgroundWorker the whole application freezes until the server has returned from it's "startUpdating" method, but is a BackgroundWorker the right way, or should I be starting up a new Thread?

I'm new to WPF so forgive me if this is a stupid question!

Member Avatar
nmaillet
Posting Pro
535 posts since Aug 2008
Reputation Points: 97 [?]
Q&As Helped to Solve: 106 [?]
Skill Endorsements: 7 [?]
 
1
 

It's not a stupid question; asking questions is a great way to learn. A BackgroundWorker creates and manages a Thread for you, and provides a few convenient features. So I'll try and give a quick explanation of how a BackgroundWorker works.

First the BackgoundWorker creates a Thread and executes the DoWork event. So everything you do in the DoWork event handler, is executed on a separate thread from the UI thread. From this Thread, you cannot access or interact with any UI components (i.e. you can't update TextBox's, ProgressBar's, etc.). One of the great features of the BackgroundWorker is the ReportProgress() method and the ProgressChanged event. You can call the ReportProgress() method like so:

private void bw_DoWork(object sender, DoWorkEventArgs args)
{
    BackgroundWorker bw = sender as BackgroundWorker;
    ...
    bw.ReportProgress(1);
    ...
}

This causes the "DoWork" thread to block (not execute) while the ProgressChanged event is executed. The event handler for this event is called on the UI thread, so it allows you to update a UI component (such as a ProgressBar). Note that ReportProgres() can also support an Object so you can pass a lot of information to the event handler. Finally, the RunWorkerCompleted event handler is called on the UI thread (when DoWork is done) allowing you to update the UI when it completes.

Hope that helps. Let me know if you have any more questions/need clarification.

Member Avatar
SCass2010
Junior Poster in Training
93 posts since Mar 2010
Reputation Points: 0 [?]
Q&As Helped to Solve: 0 [?]
Skill Endorsements: 0 [?]
 
0
 

Ah right, so using the BackgroundWorker I'm actually creating the server on a separate thread from the UI? I have the BackgroundWorker linked up to a ProgressChanged event (simple one, just increases a ProgressBar by a bit for each part that has been set up).

Would I be better just having the BackgroundWorker creating a new instance of the server, or using the private instance from the ViewModel or would it not really make a difference either way?

Member Avatar
nmaillet
Posting Pro
535 posts since Aug 2008
Reputation Points: 97 [?]
Q&As Helped to Solve: 106 [?]
Skill Endorsements: 7 [?]
 
0
 

Wouldn't really make a difference. Are you sharing the instance of the "server" with other threads? If you aren't I'd keep it local to the BackgroundWorker DoWork event handler. If you are, just make sure it's thread safe.

You
This article has been dead for over three months: Start a new discussion instead
Post:
Start New Discussion
View similar articles that have also been tagged: