StackOverflow2013

Note that there are some explanatory texts on larger screens.

plurals

PO
text
Body
copied!<p>Desclaimer - i LOVE xaml. I think it's the best thing to happen to UI technology since..well..i wanted to say "winforms" but that really sucked - so since the dawn of history!</p> <p>Let me break down your requirements from this new and improved framework:</p> <ol> <li><strong>Strongly typed bindings</strong> - While i agree it might be useful in SOME settings to specific the binding in a strongly typed way, i frequently find myself using the fact that binding is completely loose to be very useful. the runtime discovery of properties is an incredibly powerful property of Xaml and the binding mechanism. In my experience you learn pretty quickly to find and fix binding issues, and the runtime errors are very detailed. It may not be ideal - but it's pretty good.</li> <li><strong>Faster binding</strong> - <a href="http://msdn.microsoft.com/en-us/library/bb613546.aspx" rel="nofollow noreferrer">performance</a>, is fairly fast for most situations. You can always provide an ICustomTypeDescriptor to improve performance in extreme cases. As for that Bindable property with a callback - how about some kind of <a href="http://msdn.microsoft.com/en-us/library/system.windows.dependencyproperty.aspx" rel="nofollow noreferrer">Dependency Property</a>? (i do concede that the syntax is somewhat lacking). However, for most uses i found the INotifyPropertyChanged interface to be sufficient. The binding mechanism only cares about the fact that there was a change, and it works very well in it's current form. Why do you care how the framework solves this problem - as long as it works well? </li> <li><strong>Resource Dictionaries</strong> - This is another implementation issue that mostly influences the framework and it's internal working. Why do you care how they are implemented? They work pretty well. </li> </ol> <p>I suspect you might be overusing codebehind to solve problems that can and should be solved in Xaml. Which exposes you to the framework's way of solving these different issues, and which I have almost never had to deal with in WPF. The clear seperation provided by Xaml between "things that are the GUI" and "Things that are your code" makes it harder for you to interfere with the UI by using the Code. But WPF provides MANY different mechanism to solve these solutions in an elegant way by using Xaml.</p> <p>If you don't like coding it (personally i don't like messing with UI - it never ends) - Hire a Xaml Expert. They usually have better taste in UI then developers anyway. And if you can't - Learn it! it's a great tool if you take the time to understand it. No framework will solve the problem of groking it's use.</p>

Querying!

Guidance

An individual column

Larger individual text columns get their own page to allow for proper reading.

SQuiL has stopped working due to an internal error.

If you are curious you may find further information in the browser console, which is accessible through the devtools (F12).

Reload