Matt,

I know absolutely nothing about WPF and XAML, but do you actually have to put all of that databinding stuff in the XAML itself? Wouldn't it make more sense to put as much of that coding type of stuff in the C# code?

Here's my uninformed opinion/assumptions: I was under the impression that a benefit of WPF and XAML is that one could have a professsional designer design your forms/controls. This person does not need to know anything about programming.

Am I wrong about this?

~~Bonnie




>Just when I'm getting used to the strong types of .NET and C#, and relying on the intelligence of the VS2008 IDE to find my mistakes BEFORE runtime, I am unhappy with the way so many things go within quotes in XAML, and it cannot check them to make sure they are valid settings.
>
>I spent and hour troubleshooting this XAML, only to discover that I was trying to bind to a Linq-to-Sql field field that I tried to call "custno" in the XAML, but it was really called "cust_num" in the database. The project compiled and ran fine with no errors, but it would not display the value because I had typed in the name in the wrong way!
>
>In the XAML below, you can type ANYTHING for SelectedValue="{Binding Path=ANYTHING}" and it will not give an error. (The ItemsSource is set in the code-behind at runtime)
>
>
>

><ComboBox x:Name="dropdownJobStatus" Width="113" IsSynchronizedWithCurrentItem="True" AllowDrop="True"
>                                      DisplayMemberPath="company" SelectedValuePath="custno" SelectedValue="{Binding Path=cust_num}"/>
>

>
>I'm loving WPF, but It's crazy to have come so far with the other tools to go back to this. In the above, it knows the context (from containing UI control), and it could easily tell that cust_num was not valid.
>
>I mean it didn't even complain when it ran! How about "Error: Cannot bind to property CUST_NUM" at runtime. Would have saved me a ton of time.