This project is read-only.

how do I interpret this ...

May 26, 2011 at 10:28 PM

A TwoWay or OneWayToSource binding cannot work on the read-only property 'Item' of type 'UpdateControls.XAML.Wrapper.ObjectInstance`1[System.Data.DataRow]'.

I get this message. I got a dependent property of type datarow  and when I bind to it in the xaml like...    path=datarow["title"] ... I get that exception. 

Any help would be appreciated... thx

May 27, 2011 at 2:00 AM

Update controls wraps the view model, so the DataRow is hidden from the control. You need to get the wrapper out of the way. There are a few options to do that.

First, you could skip the ForView.Wrap on that view. You won't get any dependency tracking on that view.

Second, you could implement INotifyPropertyChanged on that one class. You will get dependency tracking on other view models, but not this one or its children.

Third, you could use the ViewModelBase class. You can pick and choose which properties have dependency tracking using the Get and GetCollection methods.

Hope this helps.

May 27, 2011 at 7:35 AM

Michael, just to get my mind around things....

The other properties in my class give no problem. I see them in my view. It is just that DataRow. So, is there something special about DataRow that makes it a problem?

thx

May 27, 2011 at 1:01 PM

Yes, it's related to the DataRow and the DataTable to which you are binding. DataTable does two unusual things with the bound property:

  1. It treats it as a read-write list
  2. It expects a specific data type

I say these are unusual, because most other controls don't do this. A ListBox, for example, expects a read-only list, and will bind the items template to whatever type you give it.

Update Controls is not designed to work with read-write lists. This was a compromise to make linq work in the view model the way it does. If a collection property had a setter, you would have to figure out what was different between the provided list and your linq-transformed list. I couldn't figure out a way to make this accessible.

And secondly, the specific DataRow data type is a killer. Update Controls puts a wrapper in between the view and the view model so it can inject dependency tracking code. When a control looks for a specific data type, rather than just a set of properties, it cannot tolerate that wrapper.

 

Having said all that, I realized something. There is an easier workaround than the three I mentioned above. If you manage an ObservableCollection in your view model yourself, then Update Controls will not wrap that property. It will still give you dependency tracking on all of the other properties. I'd recommend you try this solution.

May 27, 2011 at 1:39 PM
Thanks Michaell,


the reason I'm using a DataRow is because I'm working with csv-files. And it was just an easy way to load the csv in a DataRow and use it as a kind of template ...just fill in some of it's columns with new values and export the DataRow to csv... Now I got to break my head over that observable collection you mentioned. ;) I'll surf the net and see what I get.

thx for answering and for your updateControls.

On Fri, May 27, 2011 at 2:01 PM, MichaelLPerry1971 <notifications@codeplex.com> wrote:

From: MichaelLPerry1971

Yes, it's related to the DataRow and the DataTable to which you are binding. DataTable does two unusual things with the bound property:

  1. It treats it as a read-write list
  2. It expects a specific data type

I say these are unusual, because most other controls don't do this. A ListBox, for example, expects a read-only list, and will bind the items template to whatever type you give it.

Update Controls is not designed to work with read-write lists. This was a compromise to make linq work in the view model the way it does. If a collection property had a setter, you would have to figure out what was different between the provided list and your linq-transformed list. I couldn't figure out a way to make this accessible.

And secondly, the specific DataRow data type is a killer. Update Controls puts a wrapper in between the view and the view model so it can inject dependency tracking code. When a control looks for a specific data type, rather than just a set of properties, it cannot tolerate that wrapper.

Having said all that, I realized something. There is an easier workaround than the three I mentioned above. If you manage an ObservableCollection in your view model yourself, then Update Controls will not wrap that property. It will still give you dependency tracking on all of the other properties. I'd recommend you try this solution.

Read the full discussion online.

To add a post to this discussion, reply to this email (updatecontrols@discussions.codeplex.com)

To start a new discussion for this project, email updatecontrols@discussions.codeplex.com

You are receiving this email because you subscribed to this discussion on CodePlex. You can unsubscribe on CodePlex.com.

Please note: Images and attachments will be removed from emails. Any posts to this discussion will also be available online at CodePlex.com