I’m glad you found an answer. Sorry I couldn’t get to your question earlier.

Bea

Thanks a lot!!

Yeah, I can repro what you describe (by comparing the VS 2008 and VS 2010 versions of this project).

The error message I get in 2010 is:

System.Windows.Data Error: 8 : Cannot save value from target back to source. BindingExpression:Path=MethodParameters[0]; DataItem=’ObjectDataProvider’ (HashCode=40998886); target element is ‘TextBox’ (Name=’tb’); target property is ‘Text’ (type ‘String’) ArgumentException:’System.ArgumentException: Object of type ‘MS.Internal.Data.PropertyPathWorker+IListIndexerArg’ cannot be converted to type ‘System.Int32′.
at System.RuntimeType.TryChangeType(Object value, Binder binder, CultureInfo culture, Boolean needsSpecialCast)
at System.RuntimeType.CheckValue(Object value, Binder binder, CultureInfo culture, BindingFlags invokeAttr)
at System.Reflection.MethodBase.CheckArguments(Object[] parameters, Binder binder, BindingFlags invokeAttr, CultureInfo culture, Signature sig)
at System.Reflection.RuntimeMethodInfo.Invoke(Object obj, BindingFlags invokeAttr, Binder binder, Object[] parameters, CultureInfo culture, Boolean skipVisibilityChecks)
at System.Reflection.RuntimeMethodInfo.Invoke(Object obj, BindingFlags invokeAttr, Binder binder, Object[] parameters, CultureInfo culture)
at System.Reflection.RuntimePropertyInfo.SetValue(Object obj, Object value, BindingFlags invokeAttr, Binder binder, Object[] index, CultureInfo culture)
at MS.Internal.Data.PropertyPathWorker.SetValue(Object item, Object value)
at MS.Internal.Data.ClrBindingWorker.UpdateValue(Object value)
at System.Windows.Data.BindingExpression.UpdateSource(Object value)’

WPF 4.0 is supposed to be backwards compatible and shouldn’t break apps written in 3.5. So this may be a bug in 4.0.

Thanks,
Bea

I wrote about the two types of asynchronous binding in the following post: http://bea.stollnitz.com/blog/?p=27 (so old I almost forgot I had written about it)

Bea

Your points are all very valid. The more separation there is between UI and data, the more scalable the application will be long term, there’s no doubt about it.

The Model-View-ViewModel pattern is one of the most used techniques for achieving this separation in WPF. Very briefly, in this pattern the Model is your data, and the View is your UI (XAML and maybe a bit of code). The ViewModel is a layer introduced between the View and the Model that exposes the Model in a way that is more easily consumed by the View. It’s ok for the ViewModel to use certain types introduced by WPF, and to make certain assumptions about the UI. The ViewModel is usually a pretty thin layer compared to the Model, still allowing easy portability to future (or alternative) technologies. So, in this pattern, your UI bindings communicate with the ViewModel and not with the Model.

These ideas were introduced by John Gossman in his blog a while ago. John was an architect in Blend at the time, so his post explains in a high-level how Blend was designed. I’m also a big fan of Dan Crevier’s approach to this pattern (he was an architect in Max, another product that was heavily using WPF). Dan uses a slightly different terminology compared to John, but the basic idea is the same. I especially like how Dan deals with commanding in his approach.

You ask why we added a feature that allows binding to methods. Well, as most of the features we add, this was introduced based on customer feedback, in the context of binding to web services. Users felt that creating a simple application that binds to a web service’s method is a common enough scenario that shouldn’t require code behind.

In general, the main advantage of allowing a certain scenario to be created using XAML only is the fact that it becomes toolable. This is a huge advantage – it opens scenarios to designers and less advanced developers, and speeds up development for advanced developers.

My guess is that a large application that is following M-V-VM or any other pattern that allows clean separation between UI and data will likely not use binding to methods as a common practice. Also, any property and object names that it refers to in XAML will be referring to the ViewModel, and not the Model itself.

Thanks for your great comment.

Bea