On Thu, May 27, 2010 at 10:38 AM, David Kean <[email protected]> wrote: > It's also more than just refactoring - requirements change; instead of > binding to this > property, you are now binding to this other property, or to a different > object altogether. > The problem with the way binding is setup both in Silverlight, WPF and > WinForms is > that you don't find out about these things until runtime. In the > Silverlight/WPF case > binding to a non-existent property doesn't even cause a runtime failure - > you need > to look at tracing to see these.
Fair enough. > An example of how easy this is miss; attach to Visual Studio to itself and > see how > binding failures there are from WPF. Had they used something similar to > below, they > would have found these problems as soon they hit the compile button. Agreed. I'm not denying the usefulness, I'm more denying the neccessity. But yeah, fairly useless to continue arguing about it. Point proven; there are uses and I no longer consider it stupid. There's probably some sort of ideal binding environment that's not being realised. Might be worth thinking about. -- silky http://www.programmingbranch.com/
