从数据源拖放到WPF窗口不起作用 [英] Drag and drop from datasource to WPF window not working

问题描述

我的任务是为我公司设计一个联络管理计划。我们有VS 2012，因为我以前从未使用过WPF，我以为我会用它来开发这个应用程序。

在使用btw是数据库的数据库的实体框架首先使用绑定时，我遇到了很大的问题。

我已经按照该链接中的说明来信。
http://msdn.microsoft.com/en-us/data /jj574514.aspx

数据源窗口中显示的对象很好。但是当我拖到我的窗户，没有任何反应。不知道我在做错什么，找不到有这个问题的人。

有人可以帮我吗？我看到无处不在任何帮助不胜感激

解决方案

好的。我实际上是通过这篇文章，只是为了表现出诚意，让你知道我真的想帮助你。

我得出以下结论：

• 该文章展示了从实体框架上下文中获取数据并在WPF DataGrid中显示数据的非常基本的场景。


• 它没有任何类型的验证或业务规则。


• 它没有任何UI行为，例如有条件地启用/禁用或显示/隐藏任何UI元素。


• 这种情况是除了获取/保存DB数据之外，设计师很有用。


• 不幸的是（幸运的是，我们所有的开发人员， ），大多数应用程序将需要一定程度的验证和业务规则以及一定程度的UI逻辑。


• 当开发复杂的逻辑时，设计人员真的没有用。 $ b

您可以在不需要复杂逻辑的情况下使用设计器，但是我必须提醒您以下缺点：

• Visual Studio WPF设计器生成固定大小的固定位置UI。当在具有不同屏幕分辨率和DPI设置的计算机中执行时，这些类型的UI不能正常工作。就像winforms一样。


• 它还会生成XAML，它有许多不必要的东西（例如 x：Name =categoryIdColumn Margin =13,13,43,191这是一个非常糟糕的可维护性/可扩展性的观点）


• 已经看到，设计师生成的XAML还包含一个 CollectionViewSource ，这是一件好事和坏事。这是一件好事，因为它使 DataGrid中的设计时间数据 ，但它也是坏的，因为它使你的XAML膨胀了许多不必要的东西，并引入了不必要的< Window.Resources> 这会使事情变得复杂。

现在，这是DataGrid所需的极少的XAML，没有设计时间数据支持：

 < 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 =类别IDBinding ={Binding CategoryId}/> 
< DataGridTextColumn Header =NameBinding ={Binding Name}/> 
< / DataGrid> 
< / Window> 
  

你看？在Intellisense的帮助下键入更快（更多的是这样），而不是手动浏览属性窗口并设置这些属性所需要的。

我的建议是，你熟悉XAML，而不是坚持做艰难的事情

---

要记住的另一个非常重要的方面是，一般来说，您不要在WPF中的代码隐藏任何东西，因为这不是必需的，因此该教程实际上是针对 WPF的做法方式 ，但是这是OK，因为它实际上是一个实体框架教程，而不是WPF教程。

---

开发

你真的需要重新考虑你所说的易于开发。在UI开发方面，我称之为易于开发，实际上可以使用UI来做我想要的无需诉诸于涉及P / Invoke（无论什么意思）和所有者绘制类型的任何程序的程序代码实践。

WPF提供了真正的易于开发相对于winform展示的假冒易于开发的

• winforms可以让您与设计师做一切（这只是因为设计师生成的代码实际上是如此之小，以至于没有人会使用winforms，如果他们没有设计师），但是当谈到添加复杂的DataBinding或UI逻辑时，你永远不会再遇到winforms的无效。




• WPF鼓励手动XAML写作，不仅因为XAML是声明式的（而不是程序性的winforms方法），而且还因为可定制性和reu的级别可靠性非常高，以设计师为中心的方法没有意义。

---

拖放是简单的方法

不是没有。这其实是艰难的。简单的方法是学习XAML，并能够执行你甚至不能想象与winform有关的事情。

---

如果以设计师为中心的方法仍然存在感觉到你，你可能想尝试表达式混合

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

解决方案

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

这篇关于从数据源拖放到WPF窗口不起作用的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！