OnPropertyChanged not fired when SetProperty is called

Topics: Prism v4 - WPF 4
Jan 30, 2015 at 1:09 PM
I have created a new VB project (named TestPrismVB), installed Prism and I have written this simple code:
Imports Microsoft.Practices.Prism.Mvvm

Public Class pruebaViewModel
    Inherits BindableBase

    Private Property _oneProperty As String
    Public Property oneProperty As String
        Get
            Return _oneProperty
        End Get
        Set(value As String)
            SetProperty(_oneProperty, value)
            'IF I UNCOMMENT THIS LINE, IT WORKS:
            'OnPropertyChanged("oneProperty")
        End Set
    End Property

    Private Property _anotherProperty As String
    Public Property anotherProperty As String
        Get
            Return _anotherProperty
        End Get
        Set(value As String)
            SetProperty(_anotherProperty, value)
            oneProperty = value
        End Set
    End Property
End Class
And the XAML file is MainWindow.xaml:
<Window x:Class="MainWindow"
    xmlns="http://schemas.microsoft.com/winfx/2006/xaml/presentation"
    xmlns:x="http://schemas.microsoft.com/winfx/2006/xaml"
    xmlns:vm="clr-namespace:TestPrismVB"
    Title="MainWindow" Height="350" Width="525">
    <Window.DataContext>
        <vm:pruebaViewModel/>
    </Window.DataContext>
    <StackPanel>
        <TextBox Text="{Binding anotherProperty, UpdateSourceTrigger=PropertyChanged}"/>
        <TextBlock Text ="{Binding oneProperty}"/>
    </StackPanel>
</Window>
If you run this simple project, and you type 1234, you will see that the TextBlock updates one step behind (it will show 123 instead of 1234).

Is it a VB bug? A Prism bug? Am I doing something wrong?

Thank you
Jan 31, 2015 at 1:20 PM
I can't explain what you are describing just based on your code. But bottom line the recommended pattern when you have co-dependent properties is to use OnPropertyChanged to raise the change notification for the other property when you set it from the dependent one. So if A and B are properties that set each other, use SetProperty for the one being set, set the other, then call OnPropertyChanged for the other as the normal pattern.
Feb 4, 2015 at 7:58 AM
SOLVED:

The problem was the word PROPERTY in:
Private Property _oneProperty As String
Public Property oneProperty As String
The correct is:
Private _oneProperty As String
Public Property oneProperty As String
Thank you
Feb 4, 2015 at 2:01 PM
Edited Feb 4, 2015 at 2:05 PM
Interesting. That didn't jump out at me since I rarely use VB. Guess VB was letting that somehow silently mask the intended public property from being called. Another good reason not to like VB. :)

Snide comments aside - guessing you don't have option strict on? I would think that option strict would catch that.
Feb 17, 2015 at 9:03 PM
Interesting indeed. A couple of months ago I was struggeling with exactly this same issue and solved it with after bad struggle with myself and others who claimed I was wrong. See this article in StackOverflow.
It appears that the declaration of variables and properties in C# and VB are slightly but significantly different. And all the documentation (infortunately for VB programmers) is in C#. I don't believe Option Strict solves this, but I did not try to be honest.

Oh and BrianNoyes, if this would be a reason (what are the other ones??) to abandon VB, I would certainly stick to it. Less sexy, less techie OK, but better to understand and read. But that's a completely other discussion :-) - no offence!

Regards!
Feb 17, 2015 at 9:30 PM
Actually the reason you mention is the #1 reason I think choosing VB.NET if not already heavily invested in it is a bad idea - the majority of documentation and samples are in C# only making it a constant source of friction for VB developers. The "better able to understand and read" is not a valid argument for anyone to make or dispute about any language - those qualities are in the eyes of the beholder and are driven by the experience of the beholder and the way their brain is wired. My main reasons for being biased against VB are driven by the combination of the problem mentioned with documentation and samples (which gets worse all the time as many product teams at Microsoft are specifically choosing to allocate their budgets to shipping more features instead of spending the resources to document and provide samples in two languages), and the fact that VB is more loosely typed and lets you get away with shooting yourself in the foot in more subtle ways such as the property redeclaration here without telling you you are doing it. That last argument has weakened a lot for me as I now do a ton of JavaScript development, and that is a language that will let you point a high caliber weapon at your forehead and not tell you anything until you have blown your head off, and yet somehow that flexibility doesn't bother me there as the flexibility of VB always did. Can't fully explain that other than to say that when developing in .NET my brain knows that the underlying runtime is very strongly typed so I like my language to match the reality of the runtime as closely as possible, whereas when doing JavaScript development my brain knows that the underlying runtime is very loose so using a language that matches that makes more sense to me.
Feb 18, 2015 at 7:13 AM
@BrianNoyes: we have indeed invested heavily in VB development the last 4 to 6 years, based on earlier positive experience with the language. In fact I dislike the discussion, but every now and then someone comes up with a new argument. What I really - I mean really - need is THE argument to invest in re-education of our devteam. .... and still am looking for that argument. It seems a matter of mindset as you mention it. I completely agree on that. Close this discussion, OK?
Feb 18, 2015 at 5:58 PM
Agreed on shutting this line of discussion down. :) Was just trying to explain myself since I fell into the trap of making a snide comment about a perfectly good language.