Question

I am relatively new to MVVM, and I am trying to code up a basic Status Bar for an MVVM WPF application. I think I have the gist of things, but for some reason, the status bar does not always update, and I am not sure why.

In my ViewModel, I have a basic property that I update when I change a status message:

public string StatusMessage
{
    get { return _statusMessage; }
    set
    {
        if (value == _statusMessage) return;
        _statusMessage = value;
        base.OnPropertyChanged(() => this.StatusMessage);
    }
}

My OnPropertyChanged method (which I have in a base ViewModel class that implements INotifyPropertyChanged) looks like so (got this idea from Gunther Foidl; wish I could claim credit for it because I think it’s slick but I’m not quite that smart):

protected virtual void OnPropertyChanged<T>(Expression<Func<T>> exp)
    {
    MemberExpression me = exp.Body as MemberExpression;
    string propName = me.Member.Name;

    PropertyChangedEventHandler handler = this.PropertyChanged;
    if (handler != null)
    {
        handler(this, new PropertyChangedEventArgs(propName));
    }
}

At any rate, this all works great for all of my controls except one. On my MainWindow.xaml file, I have a StatusBarItem control bound to the above property, like so (the rest of the XAML has been trimmed for space reasons):

<StatusBarItem Grid.Column="0">
    <TextBlock TextTrimming="CharacterEllipsis" Text="{Binding Path=StatusMessage}" />
</StatusBarItem>

When I run my application (which hits a couple of DBs in addition to generating a document from template and a bunch of other fairly resource-intensive stuff), some, but not all, messages show up on the status bar. I have debugged and verified that the messages all make it into the StatusMessage property, above (and the ensuing private variable), they just don’t seem to be refreshing in the UI.

I have looked at several examples that use BackgroundWorker instances for ProgressBar controls, but haven’t seen any for StatusBarItem controls, and am not really sure how to translate one to the other.

I have also used Tasks before in previous C# 4.0 and WPF apps, and figure it’s probably a good way to go, but I haven’t really been able to figure out how/where to designate the UI task (I’ve always done it in the code-behind for the MainWindow before, but I’m striving for a zero-code-behind to stay in keeping with MVVM here).

I’m pretty sure that a multi-threaded approach is the way to go; I just don’t know enough about one approach (I know a little bit of this and a little bit of that) to make it work. I did see a couple of posts that used the older threading approach directly, but I pretty much stayed away from multithreading programming until I started using Tasks with .NET 4.0 (finding them a little easier to comprehend and keep track of), so I had a bit of trouble making sense of them.

Can anyone take pity on me and point me in the right direction, or suggest further debugging I can do? Thanks!

Answer 1

1)Reflection based binding can be source of error sometimes because of inlining. Try to see what happens if you notifypropertychanged with simple string instead of reflection.

2) if you are using multi threads there maybe a chance that you setup StatusMessage not from UIThread in that case it won’t be able to update UI, you could invoke setter code on UI Dispatcher to see if that helps

3) check whether binding works , in constructor of xaml form modify StatusMessage directly on VM and see whether the change is shown on UI without invoking multithreaded service calls which introduce additional variables to simple textblock – string binding

4) if that doesn’t help you could create a simple xaml form with single textblock bind it to your big viewmodel and see what happens, if nothing works you can begin cutting VM class to make it simpler so binding eventually starts to work and you find an error

5) if you think that statusbar is the problem see if single textblock without statusbar (extract xaml part from your example) works