Windows Store App UI update

Question

I am writing a Windows Store App toy application for Windows 8. It has just one xaml page with a TextBlock. The page has the class MyTimer as DataContext :

this.DataContext = new MyTimer();

MyTimer implements INotifyPropertyChanged and the updating of the property Time is made with a timer:

public MyTimer(){
    TimerElapsedHandler f = new TimerElapsedHandler(NotifyTimeChanged);
    TimeSpan period = new TimeSpan(0, 0, 1);
    ThreadPoolTimer.CreatePeriodicTimer(f, period);
}

with

private void NotifyTimeChanged(){
    if (this.PropertyChanged != null){
        this.PropertyChanged(this, new PropertyChangedEventArgs("Time"));
    }
}

the TextBlock has a databinding on Time

<TextBlock Text="{Binding Time}" />

When I run the application i have the following exception:

System.Runtime.InteropServices.COMException was unhandled by user code

With the message

The application called an interface that was marshalled for a different thread. (Exception from HRESULT: 0x8001010E (RPC_E_WRONG_THREAD))

The real problem is that I am updating the property of the class MyTimer, not the GUI itself, I can't figure it out, but I think the solution should use something like this one.

score 7 · Accepted Answer · answered Mar 29 '12 at 21:24

Yes, you're notifying property changes from a thread pool thread rather than the UI thread. You need to marshal the notification back to the UI thread in the timer callback. Now, your view model is separated from your view (a good thing) therefore it doesn't have a direct link to the Dispatcher infrastructure. So what you want to do is hand it the proper SynchronizationContext on which to communicate. To do this you need to capture the current SynchronizationContext during construction or allow it to be passed in explicitly to a constructor which is good for tests or if you're initializing the object off the UI thread to begin with.

The whole shebang would look something like this:

public class MyTimer
{
    private SynchronizationContext synchronizationContext;

    public MyTimer() : this(SynchronizationContext.Current)
    {
    }

    public MyTimer(SynchronizationContext synchronizationContext)
    {
        if(this.synchronizationContext == null)
        {
            throw new ArgumentNullException("No synchronization context was specified and no default synchronization context was found.")
        }

        TimerElapsedHandler f = new TimerElapsedHandler(NotifyTimeChanged);
        TimeSpan period = new TimeSpan(0, 0, 1);
        ThreadPoolTimer.CreatePeriodicTimer(f, period);
    }

    private void NotifyTimeChanged()
    {
        if(this.PropertyChanged != null)
        {
            this.synchronizationContext.Post(() =>
                {
                    this.PropertyChanged(this, new PropertyChangedEventArgs("Time"));
                });
        }
    }
}

Thanks a lot. This suggests me I will need to use the SynchronizationContext each time I use an asynchronous call… I'll think about doing something like that with the async keyword too. — Gabber, Mar 29 '12 at 22:23
Yeah, if you're using C# 4.5's await keyword, you're going to get this by default. — Drew Marsh, Mar 29 '12 at 23:39
Thanks for the answer! I just want to add a sidenote: if you want to call back in the UI context, make sure you capture the `SynchronizationContext` no sooner than the UI has been built (I use the `OnLaunched` event handler to do it), otherwise the context you grab won't serve. Further reading: http://www.codeproject.com/Articles/31971/Understanding-SynchronizationContext-Part-I — Lvsti, Sep 25 '12 at 12:48

score 5 · Answer 2 · answered Mar 30 '12 at 17:16

5

One way to do this is awaiting Task.Delay() in a loop instead of using a timer:

class MyTimer : INotifyPropertyChanged
{
    public MyTimer()
    {
        Start();
    }

    private async void Start()
    {
        while (true)
        {
            await Task.Delay(TimeSpan.FromSeconds(1));
            PropertyChanged(this, new PropertyChangedEventArgs("Time"));
        }
    }

    public event PropertyChangedEventHandler PropertyChanged = delegate { };

    public DateTime Time { get { return DateTime.Now; } }
}

If you call the constructor on the UI thread, it will invoke the PropertyChanged there too. And the nice thing is that exactly the same code will work for example in WPF too (under .Net 4.5 and C# 5).

answered Mar 30 '12 at 17:16

svick

236,525
50
385
514

Not saying this code won't work, but IME Task.Delay doesn't have very high resolution. In WPF, Win8 and WP8 tests, I set a CancellationTokenSource.CancelAfter to 8 minutes and the UI only got to 7:56 minutes. – Stonetip Jun 04 '13 at 19:49
@Stonetip It should certainly have a better resolution than 1 second, my guess is that there's something else going on in your code. Also, `Task.Delay()` is not `CacelAfter()`, though I would expect them to have the same resolution. – svick Jun 04 '13 at 23:29
Task.Delay does have better resolution than 1 second, but it you expect it to be spot-on in terms of milliseconds, then my tests across WPF, Win8 and Win Phone 8 show a inconsistent behavior of up to .5 seconds per minute. I've found, however, for the latter two environments that the ThreadPoolTimer class works great. – Stonetip Jun 07 '13 at 08:21

score 1 · Answer 3 · answered Sep 17 '12 at 11:53

1

how about the code from this blog:

http://metrowindows8.blogspot.in/2011/10/metro-tiles.html

This worked for me. I had to pass a ThreadPoolTimer object to my delegate function

answered Sep 17 '12 at 11:53

Akshat

4,515
4
27
28

Windows Store App UI update

3 Answers3

Linked