Issue in 3.0 snippet

RockoWPB posted on Wednesday, June 20, 2007

I am a new user to CSLA and on top of that reletively new to WPF(who isn't). In trying to get my first VB root BO up and running I ran into a problem I couldn't figure out for quite a while. The problem is in the "Define a CSLA property" snippet.

Private mDescription As String
Public Property Description() As String
......
Set(ByVal value As String)
      CanWriteProperty(True)
      If Not mDescription.Equals(value) Then
            mDescription = value
            PropertyHasChanged()
      End If
End Set
End Property

The blue line is the problem. Since the field mDescription hasn't been initialized it is still equal to nothing. Because of this the Equals method doesn't run and the statements inside the if never run either. So the mDescription field never gets updated and PropertyHasChanged never gets called.

I noticed in the book that the line reads like this "If mDescription <> value then" which works fine. I don't know if its a CSLA 3.0 or a VB issue or what, but it took me a few hours to figure it out. If the field is initialized it also works fine. But us VB programmers aren't used to initilizing a string field to "".

Hope this helps any newbies like me.

RockoWPB

Q Johnson replied on Wednesday, June 20, 2007

Why not just give it an initial value in the declaration? My understanding is that this was a required technique for all BusinessBase objects. So just use:

Private mDescription As String = ""

Private mDescription As String = String.Empty

RockfordLhotka replied on Wednesday, June 20, 2007

That is a partial solution, unfortunately both ASP.NET and WPF can (and do sometimes) replace an empty string with null…

Normally in VB this is a non-issue, because if you use the VB runtime’s string functions they automatically treat null/Nothing like “”. However, the .Equals() method, and other .NET runtime methods, aren’t so understanding.

Another solution is to avoid using .Equals() and instead use the <> operator – because then you are back to normal VB behavior and the null value is a non-issue.

Rocky