CoreCLR's Blog

Archive for the ‘Threading’ Category

Silverlight Feature Request: Allow Network Communication on Application Exit

Posted by coreclr on December 6, 2009

If you would like native .NET access to calling Web Services on Application Exit, then vote here:
http://silverlight.uservoice.com/pages/4325-runtime-feature-suggestions/suggestions/310806-allow-the-app-to-hit-a-web-service-on-exit?ref=title

Advertisements

Posted in .NET, Silverlight, Threading | Leave a Comment »

Async chain of service calls in Silverlight

Posted by coreclr on November 26, 2009

A colleague of mine asked me how to chain service calls in a Silverlight async model.

Lets say you have these two operations:

string GetId()
void Calculate(string id)

And you must call GetId first and then use the result of that operation to call the Calculate operation.

The solution is pretty simple. We can use our old friend; the AutoResetEvent class. Luckly this exist in Silverlight as well.

First we put the task on the ThreadPool so we don’t block the UI Thread:

private void Button_Click(object sender, RoutedEventArgs e)
{
    ThreadPool.QueueUserWorkItem(StartWork);
}

And here is the StartWork method:

public void StartWork(object state)
{
    var dataService = new DataServiceClient();
    var personService = new PersonServiceClient();

           string id = string.Empty;
           dataService.GetIdCompleted += (s, e) =>
           {
               id = e.Result;

               //signal the event, so the thread can continue
               autoResetEvent.Set();
           };

           //call GetIdAsync
           dataService.GetIdAsync();

           //pause the thread
           autoResetEvent.WaitOne();

           //call CalculateAsync with the id
           personService.CalculateAsync(id);
}

Thats it. Pretty simple.

Posted in .NET, Silverlight, Threading | Leave a Comment »

Dispatcher in Silverlight – Extension Method

Posted by coreclr on October 7, 2009

Normally when we need to update the UI from a non-UI thread, we write code that checks if we are on the UI thread or not. Like this:

ThreadPool.QueueUserWorkItem((state) =>
  {
         if (CheckAccess())
         {
             txtFirstName.Text = 
             DateTime.Now.ToString();
         }
         else
         {
             Deployment.Current.Dispatcher.BeginInvoke(() => 
             {
                 txtFirstName.Text = DateTime.Now.ToString();
             });
         }
     }
  );

But this is a lot of code, so to simplify this, we can write an extension method like this:

public static void InvokeIfNeeded(this DependencyObject ctl, Action doit)
{
  if(ctl.Dispatcher.CheckAccess())
  {
      doit();                
  }
  else
  {
      ctl.Dispatcher.BeginInvoke(doit);
  }
}

And we can then use it like this:

InvokeIfNeeded( () => txtFirstName.Text = DateTime.Now.ToString());

Note that if we access UI elements from a generated proxy, the BackgroundWorker API or from the WebClient API, Silverlight will automatic marshal the code to the UI Thread, so we don’t need to do this explicit. But if we access UI elements from a manually created Thread, a ThreadPool Thread or the HttpWebRequest API, we need to use the Dispatcher. Also note that in the Silverlight version, it’s not possible to specify a DispatcherPriority. It’s always processed with the Background priority.

Posted in .NET, Silverlight, Threading | Leave a Comment »