blocks|key|3681282|text|-编辑2|type|unstyled|depth|inlineStyleRanges|entityRanges|data|3681283|考虑到你正在尝试制作一个像你展示的那样的编辑器，我建议你更多地使用WPF。我目前的项目也有许多这样的特性，我们决定将WPF与Direct3D内容组合在一起的能力非常强大。这是很好的能够渲染你的场景到任何东西-不仅仅是一个矩形窗口。在WinForms中，你基本上只能使用一个矩形，而且那里的空域也有问题(虽然很微妙，但当菜单拉到你的hwnd上时会出现闪烁问题，等等)。带有D3DImage的WPF+compositor摆脱了所有这些问题，并允许您发挥想象力来构建非常灵活的UI。可以在WPF3D对象一侧实时渲染场景，或者直接在D3D场景上使用WPF控件，而不是尝试在d3d中执行图形用户界面，等等。|3681284|-原创|3681285|如果你打算托管DX，你可能会考虑它-特别是因为它让你能够用你的UI进行场景合成，并且如果你使用D3DImage，就不会有空域问题。|offset|length|3681286|这确实适用于SlimDX和WPF。|3681287|--编辑|3681288|有关在Winforms中使用Direct3D的缺点以及集成WPF/DX的优点的更多信息，请参阅：|3681289|MSDN+Article+on+Airspace|3681290|Codeproject+arcticle+on+intro+to+D3DImage|3681291|entityMap|0|LINK|mutability|MUTABLE|url|http://msdn.microsoft.com/en-us/library/system.windows.interop.d3dimage.aspx|1|http://msdn.microsoft.com/en-us/library/aa970688.aspx|2|http://www.codeproject.com/KB/WPF/D3DImage.aspx^0|0|0|0|1B|8|0|0|0|0|0|0|O|1|0|0|15|2|0^^$0|@$1|2|3|4|5|6|7|15|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|16|8|@]|9|@]|A|$]]|$1|D|3|E|5|6|7|17|8|@]|9|@]|A|$]]|$1|F|3|G|5|6|7|18|8|@]|9|@$H|19|I|1A|1|1B]]|A|$]]|$1|J|3|K|5|6|7|1C|8|@]|9|@]|A|$]]|$1|L|3|M|5|6|7|1D|8|@]|9|@]|A|$]]|$1|N|3|O|5|6|7|1E|8|@]|9|@]|A|$]]|$1|P|3|Q|5|6|7|1F|8|@]|9|@$H|1G|I|1H|1|1I]]|A|$]]|$1|R|3|S|5|6|7|1J|8|@]|9|@$H|1K|I|1L|1|1M]]|A|$]]|$1|T|3|-4|5|6|7|1N|8|@]|9|@]|A|$]]]|U|$V|$5|W|X|Y|A|$Z|10]]|11|$5|W|X|Y|A|$Z|12]]|13|$5|W|X|Y|A|$Z|14]]]]

----EDIT 2 -----

Given that you're trying to make an editor like the one you showed, I'd recommend going WPF even more. My current project has many features along those lines, as well, and we've decided that the ability to composite WPF with Direct3D content is extremely powerful. It's nice to be able to render your scene into anything - not just a rectangular window. In WinForms, you pretty much were limited to one rectangle, and you had issues with airspace there, too (subtle, but things like flickering issues when menus pull over your hwnd, etc). The WPF compositor with D3DImage gets rid of all of those issues, and lets you use your imagination to construct a very flexible UI. Things like rendering your scene in realtime on the side of a WPF3D object are possible, or using WPF controls directly on top of your d3d scene instead of trying to do the GUI in D3D, etc.

-----Original---------

If you're going to be hosting DX, you might want to consider it - especially since it gives you the ability to do scene composition with your UI and no airspace issues if you use <a href="http://msdn.microsoft.com/en-us/library/system.windows.interop.d3dimage.aspx" rel="noreferrer">D3DImage</a>.

This does work with SlimDX and WPF.

----EDIT-----

For more information on the disadvantages of using Direct3D with Winforms, and the advantages of WPF/DX integration, see:

<a href="http://msdn.microsoft.com/en-us/library/aa970688.aspx" rel="noreferrer">MSDN Article on Airspace</a>

<a href="http://www.codeproject.com/KB/WPF/D3DImage.aspx" rel="noreferrer">Codeproject arcticle on intro to D3DImage</a>

blocks|key|461761|text|如果你正在编写大量的自定义控件，我会选择WPF。WPF的部分设计是可扩展的、可组合的，其结果是编写自定义控件变得极其简单。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|461762|我用WinForms写过一些自定义控件，有时候会很麻烦。布局真的会占用你一些时间。我生命中的几个周末都花在了WinForm控件布局上。用WPF编写等效的控件是小菜一碟。|461763|entityMap^0|0|0^^$0|@$1|2|3|4|5|6|7|F|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|G|8|@]|9|@]|A|$]]|$1|D|3|-4|5|6|7|H|8|@]|9|@]|A|$]]]|E|$]]

If you're writing lots of custom controls I would choose WPF. Part of WPF's design is to be extendable, composable and the result is that it's dirt simple to write custom controls. 

I've done a bit of custom control writing in WinForms and it can be very challanging at time. Layout will really take some time away from you. Several weekends of my life were paid to WinForm Control Layout. Writing the equivalent controls in WPF was a cinch.

blocks|key|3681389|text|type|unstyled|depth|inlineStyleRanges|entityRanges|data|3681390|+AFAIK+WPF是WinForms的继任者，对吗？|blockquote|3681391|3681392|3681393|我不相信这是真的，因为微软可能会推动这一点。在Winforms上编写的遗留代码太多了，在不久甚至更远的将来，这将是一件现实的事情。|3681394|因此，考虑到这一点，如果您愿意，并且能够负担得起学习WPF的时间，我会这样做。否则我会使用Winforms。|3681395|entityMap^0|0|0|0|0|0|0^^$0|@$1|2|3|-4|4|5|6|L|7|@]|8|@]|9|$]]|$1|A|3|B|4|C|6|M|7|@]|8|@]|9|$]]|$1|D|3|-4|4|5|6|N|7|@]|8|@]|9|$]]|$1|E|3|-4|4|5|6|O|7|@]|8|@]|9|$]]|$1|F|3|G|4|5|6|P|7|@]|8|@]|9|$]]|$1|H|3|I|4|5|6|Q|7|@]|8|@]|9|$]]|$1|J|3|-4|4|5|6|R|7|@]|8|@]|9|$]]]|K|$]]

<blockquote>
 AFAIK WPF is the successor to WinForms, right?
</blockquote>

I don't believe this is true as much as MS might like to push this. There is just too much legacy code written on Winforms for that to be a realistic thing in the near or even somewhat distant future.

So with that in mind, if you would like to, and can afford to spend the time learning WPF I would do that. Otherwise I would use Winforms.

blocks|key|1092091|text|我们大约在9个月前就解决了这个问题。我们决定使用WPF，到目前为止，我们对这个决定很满意。是的，有一个学习曲线。这是相当可观的，特别是来自WinForms，在那里你有太多的东西要忘记。我还建议您可以访问设计器，否则您的应用程序可能会看起来有点破旧。也要为一些WPF陷阱做好准备，它们会让你花几个小时抓挠你的头，问‘为什么这这么难’。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|1092092|但WPF领先了一步。数据绑定、模板化和对窗口外观的完全控制让你认为WinForms本来就应该是这样的。|1092093|哦，是的，准备好为一些缺失的控件支付几美元。缺少一些东西，比如日期选择器和树控件上的复选框(您实际上可以将其模板化，但在这方面它不像winforms那么简单)。谢天谢地，3.5+SP1现在包括了一个网格控件。|1092094|我确信我错过了更多，但这就是我能想到的。|1092095|祝好运!|1092096|entityMap^0|0|0|0|0|0^^$0|@$1|2|3|4|5|6|7|L|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|M|8|@]|9|@]|A|$]]|$1|D|3|E|5|6|7|N|8|@]|9|@]|A|$]]|$1|F|3|G|5|6|7|O|8|@]|9|@]|A|$]]|$1|H|3|I|5|6|7|P|8|@]|9|@]|A|$]]|$1|J|3|-4|5|6|7|Q|8|@]|9|@]|A|$]]]|K|$]]

We dealt with this question about 9 months ago. We decided to go with WPF and so far we're happy with the decision. Yes, there is a learning curve. It's fairly considerable especially coming from WinForms where you have so much to unlearn. I also recommend you have access to a designer otherwise your application will probably look a bit shabby. Also be prepared for some WPF gotchas that will have you spending hours scratching your head saying 'why was this so hard'.

But WPF is a step ahead. The data binding, templating and complete control of how you want your windows to look makes you think that this how WinForms should've been originally.

Oh yes, and be prepared to shell out a couple of dollars for some missing controls. There are a couple of things missing like a Date picker and having checkboxes on tree controls (you can actually template this out, but it's not as simple as winforms in that regard). 3.5 SP1 includes a grid control now, thankfully.

I'm sure I'm missing a bunch more, but that's what I can come up with off the top of my head.

Good luck!

blocks|key|461992|text|我们刚刚也经历了这个…我们开始通过WinForms迁移到WPF。我认为这些天把WinForms抛在脑后是一个相当容易的决定。工具变得越来越好，如果你能在你的团队中找到一个真正的设计师，那么你就很少有东西不能组合在一起。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|461993|我们开始意识到我们的未来实际上不是WPF，而是Silverlight。随着Silverlight的成熟，它变得越来越接近WPF，它允许你跨平台运行。Silverlight的道路更像Adobe+Air，总有一天它会存在于浏览器之外(实际上你现在可以做到，但这是一件痛苦的事情)。我真的认为Silverlight+UI的未来将是.NET。|461994|entityMap^0|0|0^^$0|@$1|2|3|4|5|6|7|F|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|G|8|@]|9|@]|A|$]]|$1|D|3|-4|5|6|7|H|8|@]|9|@]|A|$]]]|E|$]]

We just went through this too… we started a move to WPF over WinForms. I think that these days it is a pretty easy decision to put WinForms behind you. The tooling is getting better and better and if you can get a true designer on your team there are very few things that you can’t put together.

We are starting to realize that our future is actually not WPF, but it is Silverlight. As Silverlight matures it is becoming more and more on par with WPF and it allows you to run cross platform. The path of Silverlight is more like Adobe Air and one day it will live outside the browser (actually you can do it now, but it is a pain). I really think that the future for .NET UI is going to be Silverlight.

blocks|key|4526939|text|在这种情况下，我会说跟随你的供应商(即微软)的领导。他们自己的内部产品越来越多地使用WPF；而且它的范围(想想Silverlight)和深度显然比WinForms更大。他们也越来越多地参考最佳实践来使用它。从所有证据(这里和其他地方)来看，它似乎已经准备好在黄金时间开发了。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|4526940|您对WinForms没有特别的亲和力(我猜想这是基于您的熟悉程度)。你最终还是需要转换的。在其他条件相同的情况下，一个新的项目将是一个很好的开始这个过程的地方。|4526941|entityMap^0|0|0^^$0|@$1|2|3|4|5|6|7|F|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|G|8|@]|9|@]|A|$]]|$1|D|3|-4|5|6|7|H|8|@]|9|@]|A|$]]]|E|$]]

In this case, I'd say follow the lead of your Vendor (i.e. Microsoft). Their own internal production increasingly features WPF; and it's scope (think Silverlight) and depth are clearly greater than WinForms. They also use it increasingly with reference to Best Practices. From all the evidence (here and elsewhere), it appears to be ready for Prime Time developement.

You have epressed no particular affinity for WinForms (I would guess what there is is based on familiarity). You'll need to switch eventually. A new project would be a great place to start the process, everything else being equal.

blocks|key|462110|text|最近刚刚做了一个非常类似的产品(在WPF中挖掘数据的3D查看器)，我可以肯定地推荐WPF/SlimDX。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|462111|这些工具有点松散(特别是Visual+Studio)，但WPF让开发一个带有一点Zing的应用程序变得容易得多，而不是大多数东西都有的默认控件灰色。|462112|使用3.5SP1中的D3DImage，在控件中托管SlimDX设备非常容易。|462113|总的来说，我会说WPF并不是更好的使用，只是不同而已。有些事情更好，有些则更糟。但这绝对是未来。|462114|entityMap^0|0|0|0|0^^$0|@$1|2|3|4|5|6|7|J|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|K|8|@]|9|@]|A|$]]|$1|D|3|E|5|6|7|L|8|@]|9|@]|A|$]]|$1|F|3|G|5|6|7|M|8|@]|9|@]|A|$]]|$1|H|3|-4|5|6|7|N|8|@]|9|@]|A|$]]]|I|$]]

Having just recently done a very similar product (3d viewer for mining data in WPF) I can definitely recommend WPF/SlimDX. 

The tools are a bit lax (especially Visual Studio), but WPF makes it much easier to make an app with a bit of Zing, rather than the default control grey that most things have.

Using D3DImage from 3.5SP1 it's very easy to host a SlimDX device inside a control.

Overall I'd say WPF isn't better to use, just different. Some things are better, some are worse. But it's definitely the future.

blocks|key|462166|text|我发现，一旦我掌握了Expression+Blend和WPF，我在构建UI方面就比Windows窗体更有效率。在我看来，这是新技术/工具的最大因素之一；如果你不能用新工具更快地获得与旧工具相同的结果，那么那些花哨的东西，你只用了10%25的时间，也不能弥补它。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|462167|除此之外，与表单相比，WPF还有其他优势：|462168|462169|具有XAML格式的接口，这使得微调所有那些模糊的属性或将一个控件的整个部分剪切并粘贴到另一个控件中变得更容易，|unordered-list-item|462170|WPF使模块化界面变得更容易，通过控件分解屏幕控件。表单可以在一定程度上做到这一点，但我总是发现这是一场战斗，|462171|一些花哨的东西很酷。我发现动画(故事板)的使用对于数据输入屏幕非常有用，在数据输入屏幕中，您需要根据所选择的产品或类似产品而需要不同的输入框。对于表单，您必须为每个数据输入屏幕创建一个单独的面板/表单，而对于WPF，我使用动画来隐藏和移动各种文本框。|462172|462173|entityMap^0|0|0|0|0|0|0|0^^$0|@$1|2|3|4|5|6|7|O|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|P|8|@]|9|@]|A|$]]|$1|D|3|-4|5|6|7|Q|8|@]|9|@]|A|$]]|$1|E|3|F|5|G|7|R|8|@]|9|@]|A|$]]|$1|H|3|I|5|G|7|S|8|@]|9|@]|A|$]]|$1|J|3|K|5|G|7|T|8|@]|9|@]|A|$]]|$1|L|3|-4|5|6|7|U|8|@]|9|@]|A|$]]|$1|M|3|-4|5|6|7|V|8|@]|9|@]|A|$]]]|N|$]]

I found that once I got a handle on Expression Blend and WPF I was more productive at building UIs than with Windows Forms. To my mind that's one of, if not the, biggest factor with a new technology/tool; if you can't acheive the same result as the old tool faster with the new tool then all the bells and whistles, that you only use 10% of the time, won't make up for it.

Apart from that there are other advantages WPF has over Forms:

<ul>
<li>Having the interface in XAML makes it so much easier to fine tune all those obscure properties or to cut and paste a whole section of one control into another,</li>
<li>WPF makes it a lot easier to modularise an interface, breaking a screen down control by control. Forms can do the same to an extent but I always found it a battle,</li>
<li>Some of the bells and whistles are cool. I've found the use of animations (storyboards) really useful for data entry screens where you need different entry boxes depending on which product is chosen or such. With Forms you'd have to create a separate panel/form for each data entry screen, with WPF I use an animation to hide and move the various text boxes around.</li>
</ul>

blocks|key|4527105|text|在您的例子中，WPF是有意义的。对我来说，这是一个根据应用程序选择的应用程序，因为在Windows窗体中有很多事情可以做得很好(比如快速开发业务应用程序)。我正在使用WPF为媒体中心应用程序(50英寸等离子屏幕上的媒体控制台的个人项目)编写一个不错的GUI。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|4527106|但是，如果我正在编写数据输入和显示应用程序，为了加快开发速度，我通常使用Windows窗体。XAML编辑器在Visual+Studio2010中做得更好，但仍有一段路要走。如果没有引用，就没有关于许多属性的IntelliSense帮助，所以不可能知道它们包含了什么(这是我花费大量时间通过书籍或web上的示例来查找这些值的地方)。也就是说，如果你写WPF，你可以做一些非常吸引人的用户界面。|offset|length|4527107|entityMap|0|LINK|mutability|MUTABLE|url|http://en.wikipedia.org/wiki/Extensible_Application_Markup_Language^0|0|1A|4|0|0^^$0|@$1|2|3|4|5|6|7|N|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|O|8|@]|9|@$D|P|E|Q|1|R]]|A|$]]|$1|F|3|-4|5|6|7|S|8|@]|9|@]|A|$]]]|G|$H|$5|I|J|K|A|$L|M]]]]

In your case, WPF makes sense. For me, it's an application by application choice because there are a lot of things you can do really well in Windows Forms (like rapid development of business applications). I'm using WPF to write a nice GUI for a media center application (personal project for a media console on my 50-inch plasma screen). 

However, if I'm writing a data entry and display application, I typically go with Windows Forms for speed of development. The <a href="http://en.wikipedia.org/wiki/Extensible_Application_Markup_Language" rel="nofollow noreferrer">XAML</a> editor is better in Visual Studio 2010 but still has a way to go. Without a reference there's no IntelliSense help on a lot of the property attributes so it's impossible to know what goes in them (which is where I spend a lot of my time trying to find those values, either through a book or examples on the web). That said, if you do WPF write, you can make some very compelling user interfaces.

blocks|key|462302|text|我知道这是一个古老的帖子，但我认为这仍然是一个有效的问题。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|462303|我在我工作的第一家公司用了3年的WinForms。那里有一些非常优秀的程序员，他们找到了一些非常聪明的方法来做一些非常酷的事情。WinForms经受住了时间的考验。它是一个可靠、可靠、高效的平台。许多人以及大大小小的公司已经使用WinForms多年了，而且这项技术已经一次又一次地证明了自己。即使你是微软，像这样的惰性也很难克服。|462304|不过，WPF绝对是未来的发展方向。微软通过制作Visual+Studio2010和Expression+Blend等产品明确了这一点。(在将WPF用于内部项目时，Microsoft被迫修复了许多问题，例如字体呈现和速度问题，这些问题最初阻止了人们采用它。Visual+Studio2010表明WPF早就可以投入生产了。|462305|那么，用WinForms还是WPF编写你的程序更好呢？答案是:+WPF。我这么说有两个原因。首先，因为微软在内部支持它，我们可以假设它将存在很长一段时间。微软向我们展示了它是下一个选择的工具，这让我想到了下一个观点:它已经变得比WinForms更好(我采访过的一些人不同意这一点，但这是事实，而且每天都变得越来越明显)。WPF有许多WinForms+(可能)永远不会提供的功能，比如集成的支持惊人的数据绑定，以及基于时间轴的动画，可以轻松地为你的应用程序制作令人惊叹的主题，并将有设计师恳求做出改变。WPF有更多的东西是无法用评论来描述的，但对我来说这是两个重要的东西:)|462306|这就是说，我知道在WPF中没有什么是在WinForms中做不到的。你可以用任何语言做任何事情，如果你非常想做的话。问题是，WinForm会让你在谷歌上搜索别人是如何做了很酷的事情，WPF内置了对微软认为是Windows未来的所有功能的支持，并将它们放在你的指尖上。|462307|随着时间的推移，人们将习惯于直接构建到Windows中的新功能，并期望它们在他们使用的所有应用程序中都可用。这将达到这样的地步，任何不支持它们的东西都会让人感觉笨拙，不太有用，看起来也不值得花钱。(我认为Touch集成就是最明显的例子。尽管有一些可以夹在显示器上并模拟鼠标的触摸屏解决方案，但在任何计算机上，触摸屏技术都取得了长足的进步，而且随着Windows8模糊了桌面设备和移动设备之间的界限，人们很可能希望以一种如果应用程序使用WinForms就很难实现的方式来使用应用程序。)|462308|我相信，迟早，对WinForms的支持和开发将停止，所有留下自己的人都将被迫迅速地迁移。然而，有太多的程序依赖于WinForms，微软无法在不久的将来放弃它。谁知道会发生什么呢。也许WinForms之于微软，就像安腾处理器之于英特尔，尽管有更好的解决方案可用，但英特尔拥有足够的用户来维持它的发展。(+http://arstechnica.com/business/news/2011/06/ask-ars-why-itaniumask-ars-with-xeons-improvement-why-bother-with-itanium.ars+)|offset|length|462309|所以我的建议是:对于新的开发，切换到WPF。派一些员工参加培训课程，或者让他们玩一段时间，这样他们就可以对技术有更好的感受。学习曲线将是陡峭的，但这样做将增加您的团队的技能，因为通过学习WPF，他们也将很好地学习SilverLight，这与WPF非常相似，对于熟悉WPF的人来说能够快速学习，但它是为web而不是桌面设计的。这是有价值的，因为用WPF重写的应用程序将更容易在以后转换为Web应用程序。WPF是新的，但它的出现是有原因的，而不仅仅是为了让人们学习其他东西。它的设计目的是使应用程序更加用户友好、直观和可移植。它的设计目的是帮助开发人员使他们的应用程序适应计算机的新时代。|462310|关于用WinForms编写的应用程序:我认为可以有把握地认为，仅仅因为WinForms获得了大量的支持，它在相当长的一段时间内仍然会受到支持。我建议让您的团队熟悉WPF，并慢慢开始将您的应用程序迁移到WPF。花点时间在微软允许的范围内，不要着急，但永远要记住，无论如何，WinForms的日子已经结束了，虽然没有人能确定会发生什么，但一旦有理由，对遗留产品的支持就会被放弃。即使WinForms应用程序被保留了很多年，重要的是要记住，时代在变化，我们都需要随着它们而改变。|462311|entityMap|0|LINK|mutability|MUTABLE|url|http://arstechnica.com/business/news/2011/06/ask-ars-why-itaniumask-ars-with-xeons-improvement-why-bother-with-itanium.ars^0|0|0|0|0|0|0|47|3E|0|0|0|0^^$0|@$1|2|3|4|5|6|7|11|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|12|8|@]|9|@]|A|$]]|$1|D|3|E|5|6|7|13|8|@]|9|@]|A|$]]|$1|F|3|G|5|6|7|14|8|@]|9|@]|A|$]]|$1|H|3|I|5|6|7|15|8|@]|9|@]|A|$]]|$1|J|3|K|5|6|7|16|8|@]|9|@]|A|$]]|$1|L|3|M|5|6|7|17|8|@]|9|@$N|18|O|19|1|1A]]|A|$]]|$1|P|3|Q|5|6|7|1B|8|@]|9|@]|A|$]]|$1|R|3|S|5|6|7|1C|8|@]|9|@]|A|$]]|$1|T|3|-4|5|6|7|1D|8|@]|9|@]|A|$]]]|U|$V|$5|W|X|Y|A|$Z|10]]]]

I know this is an old post, but I think it's still a valid question.

I used WinForms for 3 years at the first company I worked for. There were some really good programmers there, and they found some very clever ways to do some very cool things. WinForms has stood the test of time. It is a solid, reliable and efficient platform. Many people, and many companies both large and small have been using WinForms for years, and the technology has proven itself time and time again. Inertia like that is hard to fight, even if you are Microsoft.

Still, WPF is definitely the future. Microsoft made that clear by making products such as Visual Studio 2010 and Expression Blend with it. (In using WPF for internal projects, Microsoft was forced to fix many of the issues, such as font rendering and speed issues, that prevented people from adopting it at first. Visual Studio 2010 shows that WPF has long been ready for production.

So, is it better to write your program in WinForms or WPF? The answer is this : WPF. I say this for two reasons. Firstly, because Microsoft is supporting it internally, we can assume that it will be around for a very long time. Microsoft has shown us that it is the next tool of choice which leads me to my next point: it has become superior to WinForms (some people I have spoken to disagree, but it is the truth nonetheless, and is becoming more obvious every day). WPF has a host of features that WinForms will (probably) never be given, such as integrated support amazing data binding, and timeline based animations that make it easy to make amazing themes for your apps, and will have designers begging to make the switch. There is much more to WPF than can ever be described in a comment, but these are two big ones for me :)

This being said, I know there is nothing you can do in WPF that you cannot do in WinForms. You can do anything in any language if you want to badly enough. The point is that where WinForm's will leave you scouring google for how somebody else did something cool, WPF ships with built-in support for all the features that Microsoft considers to be the future of Windows and puts them right at your fingertips.

Over time, people will become used to new features build directly into Windows, and will come to expect them to be available in all the applications they use. This will reach the point where anything that doesn't support them will feel clunky, less usable, and seem less worth spending money on. (I see Touch integration as the most obvious example of this. Although there are touch screen solutions that clamp onto a monitor and emulate a mouse, on any computer, touch screen technology has come a very long way, and with Windows 8 blurring the line between the desktop and mobile devices, people will likely want to use applications in a way that will be exceptionally difficult to implement if your application uses WinForms.)

Sooner or later, I believe that support and development for WinForms will stop, and everybody that left themselves behind will be forced to port, and quickly. However, there are too many programs out there that rely on WinForms for Microsoft to be able to drop it in the near future. Who knows what will happen. Perhaps WinForms will be to Microsoft what Itanium Processors are to Intel, the product that has enough users that to keep it going, even though there are better solutions available. ( <a href="http://arstechnica.com/business/news/2011/06/ask-ars-why-itaniumask-ars-with-xeons-improvement-why-bother-with-itanium.ars" rel="noreferrer">http://arstechnica.com/business/news/2011/06/ask-ars-why-itaniumask-ars-with-xeons-improvement-why-bother-with-itanium.ars</a> )

So my advice would be this: regarding new development, make the switch to WPF. Send some staff on training courses, or let them play for a while so they can get a better feel for the technology. The learning curve is going to be steep, but doing this will increase your team's skill set because by learning WPF, they will also be well on their way to learning SilverLight, which is similar enough to WPF for people familiar with WPF to be be able to learn it quickly, but is designed for the web rather than the desktop. This is valuable because apps rewritten in WPF will far easier to convert to Web Apps later down the line. WPF is new, but it was made for a reason, not simply for the sake of making something else for people to learn. It was designed to make applications more user friendly, intuitive, and portable. It was designed to help developers make their applications fit into the new age of computers.

Regarding applications written in WinForms : I think it's safe to assume that WinForms will still be supported for quite a long time simply because of the amount of support it has gained. I would recommend letting your team familiarize themselves with WPF, and slowly start moving your applications over to WPF. Take all the time that Microsoft allows and don't rush the process, but always keep in mind that, one way or another, WinForms day's are over, and although nobody can be sure what will happen, support for the legacy product will be dropped as soon as it can be justified. Even if WinForms applications are kept around for many years, it is important to remember that times are changing, and we all need to change with them.

blocks|key|462369|text|值得一提的是，现在是2020年，我已经使用MVVM和Windows窗体用WPF编写了桌面应用程序。我必须说，我并不怀念为WPF编写样板类型的代码，例如Converters的类，使用某种类型的事件中介器在视图、命令等之间进行通信。使用MVVM+Light可以帮助解决这个问题。我喜欢WPF/MVVM中干净的代码分离，但对于小型项目，我认为不能低估快速推出Windows窗体应用程序的能力。对于图形密集型应用程序，WPF的性能将优于Windows窗体。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|462370|这些天，我倾向于在可能的情况下倾向于web开发，因为web可以在任何有网络连接的地方使用。当然，web开发通常也有较长的产品交付时间。一个积极的方面是，您已经知道的C#可以转换为ASP.NET开发。|462371|entityMap^0|0|0^^$0|@$1|2|3|4|5|6|7|F|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|G|8|@]|9|@]|A|$]]|$1|D|3|-4|5|6|7|H|8|@]|9|@]|A|$]]]|E|$]]

For what it's worth, it's 2020, and I have written desktop applications in both WPF using MVVM and Windows Forms. I must say that I do not miss writing boilerplate type of code for WPF, such as classes for Converters, using some sort of event mediator to communicate between views, Commands, etc. Using MVVM Light can help with that problem. I like the clean separation of code in WPF/MVVM, but for small projects, I think the ability to very quickly push out a Windows Forms application cannot be understated. For graphic intensive applications, WPF will perform better than Windows Forms.
These days, I tend to lean towards web development when possible since the web is available anywhere there's a network connection. Of course, web development typically has a longer product delivery as well. A positive, is that the C# that you already know, can translate to development in ASP.NET.

For a brand new application, is it better to use WPF over Windows Forms? I used Windows Forms before but not much WPF. As far as I know, WPF is the successor to Windows Forms, right?

The application is going to host DirectX Windows (not WPF 3D, but <a href="http://en.wikipedia.org/wiki/Managed_DirectX" rel="noreferrer">Managed DirectX</a> and <a href="http://en.wikipedia.org/wiki/SlimDX" rel="noreferrer">SlimDX</a>) with lots of custom controls.

EDIT: The application is a 3D related application, editor, such as <a href="http://en.wikipedia.org/wiki/Modo_%28software%29" rel="noreferrer">modo</a>:

<img src="https://i.stack.imgur.com/l6Gk3.jpg" alt="Image created using the 3D painting program modo.">

Is it better to use WPF over Windows Forms?

翻译质量差，导致语言生硬或混乱。

没有提供实际的解决方法或示例。

解答不清晰，无法理解或解决问题。

页面排版不美观，阅读体验差。

文章

问答

视频

学习中心

腾讯云实验室

直播

竞赛

腾讯云代码分析专区

腾讯iOA零信任安全管理系统专区

腾讯云架构师技术同盟交流圈

腾讯云数据库专区

腾讯云顾问专区

腾讯云原生专区

腾讯混元专区

腾讯云TCE专区

腾讯云Lighthouse专区

腾讯云HAI专区

腾讯云Edgeone专区

腾讯云存储专区

腾讯云智能专区

腾讯轻联专区 

腾讯云开发专区

TAPD专区

腾讯轻量云游戏服专区

腾讯云最具价值专家

腾讯云架构师技术同盟

腾讯云创作之星

腾讯云开发者先锋

腾讯云代码助手

云原生构建

TAPD 敏捷项目管理

Cloud Studio

SDK中心

API中心

命令行工具

涵盖代码开发、场景应用、自动测试全流程，助你从零构建专属AI助手

一站式MCP教程库，解锁AI应用新玩法

对于一个全新的应用程序，使用WPF胜过Windows窗体更好吗？我以前使用过Windows窗体，但不太使用WPF。据我所知，WPF是Windows窗体的继任者，对吗？该应用程序将托管具有大量自定义控件的DirectX窗口(不是WPF3D，而是和)。编辑:该应用程序是与3D相关的应用程序，编辑器，如​​

问在Windows窗体上使用WPF更好吗？
EN

Stack Overflow用户

社区

活动

圈层

关于

腾讯云开发者

热门产品

热门推荐

更多推荐

问在Windows窗体上使用WPF更好吗？EN