Drag and drop from datasource to WPF window not working

Question

I have been tasked to design a contact management program for my company. We have VS 2012 and since I have never used WPF before I thought I would use it to develop this application.

I am having huge problem getting started on the binding when utilizing the entity framework for the database which btw is database first.

I have followed the instructions within this link to the letter. http://msdn.microsoft.com/en-us/data/jj574514.aspx

The objects show up in the data sources window just fine. But when I drag and drop to my window, nothing happens. No idea what I am doing wrong and cannot find anyone else with this problem.

Can anyone help me out here? I have looked everywhere. Any help is appreciated

Answer 1

Ok. I actually went thru that article, just to show good faith and let you know that I actually want to help you.

I came to the following conclusions:

• That article show a very basic scenario of getting data from an Entity Framework context and showing it in a WPF DataGrid.
• It doesn't have any kind of validation nor business rules.
• It doesn't have any UI behavior such as conditionally enabling/disabling or showing/hiding any UI elements.
• That kind of scenario is where the Designer is useful, when you don't actually need anything except getting / saving data from / to a DB.
• Unfortunately (or fortunately for all of us developers who make a living of it), most applications will require some level of validation and business rules and some level of UI logic.
• The designer is really useless when it comes to developing complex logic.

You can use the designer for such situations where you don't require complex logic, however I must warn you the following cons:

• The Visual Studio WPF designer produces fixed-size, fixed-position UIs. these type of UIs don't work well when executed in computers with different screen resolutions and DPI settings. Just like winforms.
• It also produces XAML that has many unnecessary things (such as x:Name="categoryIdColumn" and things like Margin="13,13,43,191" which are really bad from a maintainabilty / scalability point of view)
• From what I've seen, the designer-generated XAML also contains a CollectionViewSource, this is both a good thing and a bad thing. It's a good thing because it enables Design-Time Data in the DataGrid, but it is also bad because it bloats your XAML with lots of unneeded things and introduces unnecessary <Window.Resources> that complicate things up.

Now, this is the very minimal XAML needed for that DataGrid, without Design-time data support:

<Window x:Class="MiscSamples.DesignTimeDataGrid"
        xmlns="http://schemas.microsoft.com/winfx/2006/xaml/presentation"
        xmlns:x="http://schemas.microsoft.com/winfx/2006/xaml"
        Title="DesignTimeDataGrid">
    <DataGrid ItemsSource="{Binding}" AutoGenerateColumns="False">
        <DataGridTextColumn Header="Category Id" Binding="{Binding CategoryId}"/>
        <DataGridTextColumn Header="Name" Binding="{Binding Name}"/>
    </DataGrid>
</Window>

You see? It's actually faster to type that (much more so with the help of Intellisense) than what it takes for you to browse the property window and set these properties manually.

My suggestion is that you get familiar with XAML instead of insisting in the hard way to do things

---

Another very important aspect to keep in mind is that generally speaking, you don't put anything in code-behind in WPF because it's not needed, therefore that tutorial is actually going against the WPF Way of doing things, but that's Ok because it's actually an Entity Framework tutorial, not a WPF tutorial.

---

ease of development

You really need to reconsider what you call "ease of development". When it comes to UI development, I call "ease of development" to actually being able to do what I want with the UI without having to resort to shitty procedural code practices involving P/Invoke (whatever that means) and "owner draw" type of things for evertyhing.

WPF provides REAL ease of development as opposed to the fake ease of development exhibited by winforms

• winforms lets you do everything with a designer (and this is just because the code the designer generates is actually so shitty that nobody would have ever used winforms if they didn't have the designer) but then when it comes to adding complex DataBinding or UI logic you're stuck with winforms' incapabilities forever.

• WPF encourages manual XAML writing, not only because XAML is declarative (as opposed to the procedural winforms approach), but also because the levels of customizability and reusability are so high that a designer-centric approach does not make sense.

---

drag and drop is the easy way out

No it's not. It's actually the hard way. The easy way is to learn XAML and be able to do Things you can't even imagine to do with winforms.

---

If a designer-centric approach still makes sense to you, you may want to try Expression Blend