Invalid cross-thread access in Silverlight app

Question

I am using the Hammock framework to make asyncronous service calls from a Silverlight application to Rest services. In the 'completed' callback I am updating an ObservableCollection that is bound to a combobox on the view.

An 'Invalid cross-thread access' exception is being thrown in the 'OnPropertyChanged' event handler.

Is this becasue Hammock is not executing the callback on the UI thread? If not, why not? That would seem to be functionality that the framework should handle. Am I missing something? I sure do not want to handle the invoking of the UI thread myself in each completed handler.

public void LoadMyData()
{
    var request = new RestRequest();
    request.Path = "MyRestUrlText";

    var callback = new RestCallback(
      (restRequest, restResponse, userState) =>
      {
        var visibleData = new ObservableCollection<MyDataType>();

        var myData = JsonConvert.DeserializeObject<MyDataType[]> restResponse.Content);

        foreach (var item in myData)
            visibleData .Add(item);

        this.MyBoundCollection = visibleData;
        OnPropertyChanged("MyBoundCollection");
    });

    var asyncResult = _restClient.BeginRequest(request, callback);
}

Thanks

score 8 · Accepted Answer · answered Jul 08 '11 at 12:33

For bound properties and properties that are collections (and not children in observable collections) it is only the OnPropertyChanged that needs to be on the UI thread. The properties can change earlier, but the UI will not change bindings until OnPropertyChanged is called.

All our ViewModels derive from a ViewModelBase we created that implements a helper SendPropertyChanged like below (so we never have to worry about cross-threading).

All our notify properties call that instead of calling OnPropertyChanged directly.

It also exposes a generally useful OnUiThread method so you can execute arbitrary code on the UI thread:

protected delegate void OnUiThreadDelegate();

public event PropertyChangedEventHandler PropertyChanged;

public void SendPropertyChanged(string propertyName)
{
    if (this.PropertyChanged != null)
    {
        this.OnUiThread(() => this.PropertyChanged(this, new PropertyChangedEventArgs(propertyName)));
    }
}

protected void OnUiThread(OnUiThreadDelegate onUiThreadDelegate)
{
    if (Deployment.Current.Dispatcher.CheckAccess())
    {
        onUiThreadDelegate();
    }
    else
    {
        Deployment.Current.Dispatcher.BeginInvoke(onUiThreadDelegate);
    }
}

If you are not using MVVM, a) apologies and b) shame on you :)

I am using MVVM. I was aware that the only code that needs to be on the UI thread is the OnPropertyChanged. But I did not think of putting BeginInvoke in there. Great suggestion. — Jim Reineri, Jul 08 '11 at 12:42

score 3 · Answer 2 · answered Jul 08 '11 at 12:05

3

Hammock is running your request on a background thread, and you absolutely want to run it there and handle the switch back to the UI thread yourself. Otherwise you block the UI thread and your application will appear unresponsive.

To switch back to the UI tread you need a handle on the Dispatcher. The easiest way to get it is like so

Deployment.Current.Dispatcher.BeginInvoke(() => {
    this.MyBoundCollection = visibleData;
    OnPropertyChanged("MyBoundCollection");
});

answered Jul 08 '11 at 12:05

Chris Sainty

9,086
1
26
31

That is what I did and what I meant when I said "I sure do not want to handle the invoking of the UI thread myself in each completed handler." I understand that the web service execution needs to happen on a background thread, but why can Hammock not invoke the callback on the UI thread instead of making you and I do it explictily in every callback? – Jim Reineri Jul 08 '11 at 12:18
Winforms has the same rules about access UI elements only from the UI thread. In my experience doing async web service calls to classic ASP SOAP web services using the .NET framework I have never had to deal with this issue. I always assumed (dangerous, I know) that was because the framework was invoking the callback on the UI thread. I was expecting Hammock to work the same way. – Jim Reineri Jul 08 '11 at 12:26
@Jim But then your processing of the response content would be on the UI thread. So if you are loading it up into an XML or JSON parser all that will tie up the UI thread. I think they do it right way. – Chris Sainty Jul 09 '11 at 07:06
True, but is that really significant? I always thought that processing web service calls on background thread was to prevent browser 'lock-up' during a slow response from a server which could potentially be several seconds. I would expect that parsing results would not be more that a few milliseconds. At any rate, thanks for the great answer and the thoughtful discussion. – Jim Reineri Jul 11 '11 at 12:37

score 0 · Answer 3 · edited Oct 18 '12 at 21:05

I did like below

namespace IdleStateDetection
{

  public partial class App : Application
  {

    private bool idle = true;

    private System.Threading.Timer _sessionTimeOutTimer = null;

    public App()
    {
      this.Startup += this.Application_Startup;
      this.Exit += this.Application_Exit;
      this.UnhandledException += this.Application_UnhandledException;

      Application.Current.RootVisual.MouseMove += new MouseEventHandler(RootVisual_MouseMove);
      Application.Current.RootVisual.KeyDown += new KeyEventHandler(RootVisual_KeyDown);

      _sessionTimeOutTimer = new Timer(SessionTimeOutCheck, null, 20000, 60000);
      InitializeComponent();
    }

    private void Application_Startup(object sender, StartupEventArgs e)
    {

      this.RootVisual = new MainPage();
    }


    void RootVisual_KeyDown(object sender, KeyEventArgs e)
    {
      idle = false;

    }

    void RootVisual_MouseMove(object sender, MouseEventArgs e)
    {
      idle = false;

    }

    private void SessionTimeOutCheck(object state)
    {
      if (Deployment.Current.Dispatcher.CheckAccess())
      {
        ShowMessage();
      }
      else
      {
        Deployment.Current.Dispatcher.BeginInvoke(()=>{ShowMessage();});
      }

    }

    private void ShowMessage()
    {
      if (idle == true)
      {
        MessageBox.Show("Idle");
      }
    }

    private void Application_Exit(object sender, EventArgs e)
    {

    }

    private void Application_UnhandledException(object sender, ApplicationUnhandledExceptionEventArgs e)
    {
      // If the app is running outside of the debugger then report the exception using
      // the browser's exception mechanism. On IE this will display it a yellow alert 
      // icon in the status bar and Firefox will display a script error.
      if (!System.Diagnostics.Debugger.IsAttached)
      {

        // NOTE: This will allow the application to continue running after an exception has been thrown
        // but not handled. 
        // For production applications this error handling should be replaced with something that will 
        // report the error to the website and stop the application.
        e.Handled = true;
        Deployment.Current.Dispatcher.BeginInvoke(delegate { ReportErrorToDOM(e); });
      }
    }

    private void ReportErrorToDOM(ApplicationUnhandledExceptionEventArgs e)
    {
      try
      {
        string errorMsg = e.ExceptionObject.Message + e.ExceptionObject.StackTrace;
        errorMsg = errorMsg.Replace('"', '\'').Replace("\r\n", @"\n");

        System.Windows.Browser.HtmlPage.Window.Eval("throw new Error(\"Unhandled Error in Silverlight Application " + errorMsg + "\");");
      }
      catch (Exception)
      {
      }
    }


  }

}

Invalid cross-thread access in Silverlight app

3 Answers3

Linked