Old-Fashioned Binding method - bound fields not changing

Old-Fashioned Binding method - bound fields not changing

Old forum URL: forums.lhotka.net/forums/t/1333.aspx

matt tag posted on Tuesday, September 26, 2006

I'm finally getting into using CSLA 2.0 for a small project, and I'm running into some problems using binding. I haven't learned any of the "new fangled" binding stuff yet (ObjectDataSource, etc), so I'm still just using the older style stuff, where you manually set Databindings and bind a Checkbox to IsDirty.

I have an object that I'm editing that contains an ID and a Name property, and they're related to each other. The object looks something like this

readonly property Id as integer
get
  return fID
end get
end prop


readonly property Name as string
get
  return fname
end get
end prop

public sub SetName(nID as int, cName as string)
if nID <> fID then
  fID = nID
  fName = cName
  MarkDirty
endif
end sub

In CSLA 2.0, the MarkDirty doesn't appear to be working correctly. I've got a textbox bound to cName, and a checkbox bound to IsDirty, neither appear to be updated when I call SetName

matt tag

RockfordLhotka replied on Tuesday, September 26, 2006

The new binding scheme relies entirely on a PropertyChanged event. So there is no IsDirtyChanged event any longer, and PropertyChanged is never raised for the IsDirty property.

In other words, the IsDirty checkbox hack won't work...

If you want to use that approach, you'll need to override OnUnknownPropertyChanged() and raise your own IsDirtyChanged event. You should be able to subclass BusinessBase(Of T) to add this functionality - just make sure to declare your IsDirtyChanged event like I do with the Saved event in BusinessBase in version 2.1.

matt tag replied on Tuesday, September 26, 2006

I don't necessarily need to use the IsDirty hack, I just need to know the minimum set of steps required so that when I change a property value "behind the scenes", any controls bound to that property get updated.

thanks,
matt tag

ajj3085 replied on Tuesday, September 26, 2006

Not sure what you mean by 'change the property behind the scenes,' but typically as long as you raise a propertychanged event for the propery which was changed it will update. 

I stronglly recommend creating a BindingSource component on your form though and bind controls to that.  It works much better.

Databinding is simple. I recommend learning the 'new' way is its all done via the designer, meaning less code you have to maintain.  Create an object Data Source and base it on your BO class.  Set the DataSource on the BindingSource to this newly created data source.

Bind your controls (via the designer) to the binding source.  For example, you can set the Text property of a text box to a string property exposed by the BindingSource.

Then, when your form loads, you do:

MyBindingSource.DataSource = myInstanceBO;

And off you go.

RockfordLhotka replied on Tuesday, September 26, 2006

I haven't really spent time with the old binding scheme in 2.0, so I don't know what you'll have to do...

I'd really recommend you switch to using a bindingsource object between your controls and objects - it solves a whole raft of 1.1 issues...

CSLA .NET 2.0.3+ raises PropertyChanged("") for any unknown property changes. This tells data binding that something changed, so it can refresh everything. It may be the BindingSource control that is actually making this work properly, I'm not sure.

If it isn't working for you, with old-style bindings, then that is pretty decent evidence that it is the bindingsource doing the work. In that case, your options are probably to either switch to using a  bindingsource, or to declare your own IsDirtyChanged event and raise it as I described in my previous post.

matt tag replied on Tuesday, September 26, 2006

ok, I've switched over to the ObjectDatasource and all the bizarre problems have gone away. Consider me converted....

matt tag

thomasc@magenic.com replied on Tuesday, September 26, 2006

Matt,

Why you using a function for setting the name?  You can do "Gets" and "Sets" for properties.  My guess is simply style, since you are applying light logic there.

Tom Cole

Copyright (c) Marimer LLC