GDI+ 之间的 C# 转换 和WPF
我正在考虑将我的 C# 应用程序从使用自定义 GDI+ 绘制控件迁移到使用自定义控件等的 WPF 应用程序。我想知道涉及什么以及会发生什么。
人们可以推荐一些可能有帮助的资源吗？ 或者确实有任何可能有益的个人经历？
I'm considering migrating my c# application from using custom GDI+ drawn controls to a WPF application with custom controls etc. I would like to know what's involved and what to expect.
Are there any resources people can recommend that might help? Or indeed any personal experiences that might be beneficial?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（3）
（对于这么长的帖子，我提前表示歉意...我想传达的内容太多...希望它对您有所帮助。）
这就是我们现在正在做的事情（迁移 Windows 窗体）大量使用自定义 (GDI+) 绘制控件到 WPF 的应用程序）。 事实上，我在团队中的角色是构建这些 GDI+ 控件……现在是构建 WPF 控件。
我同意 Bijington 的观点，即从头开始让您的应用程序完全 100% WPF 是可行的方法……如果您能说服当局走这条路。 但是，我们自己正在就地转换我们的 Windows 窗体应用程序，利用 WPF 互操作 功能。 虽然存在一些限制，但总的来说，这是一种有效的方法（并且不像我预期的那样令人沮丧）。
我建议您使用一个 GDI+ 控件并在 WPF 中构建相同的控件。然后，当您完成后，将其扔掉并重新进行。 你总是会在第一次努力中学到一些东西……并发现有更好的方法来做到这一点。 我会从小事开始......自定义按钮是一个很好的起点。
完成上述操作将使您了解您想做的其他所有事情所需的条件。
我要警告您的一件事是 WPF 的学习曲线，特别是如果您有 Windows 窗体背景……尤其是如果您要构建自定义外观的控件。 正如安倍所说，这是一个完全不同的世界。 WPF 确实带来了很多功能，但这种功能是以学习如何使用它为代价的。 Abe 提到 WPF 中的自定义控件“看起来毫无外观”，并且可以通过 ControlTemplate 提供它们的“外观”。 这只是 WPF 中提供自定义外观的用户界面的众多方法之一。
让我列举一些其他方法：
在 Windows 窗体中，就像他们给了您一把锤子 (UserControl) 和一把螺丝刀 (Control)。 然而，在 WPF 中...他们为您提供了包含所有 100 个工具的整个工具箱。 这是学习曲线比正常情况更大的部分原因。 然而，现在您可以拿起以前从未用过的锯子，用它锯掉 2x4 的末端，而不是使用锤子和/或螺丝刀来尝试做同样的事情。
资源
（好消息是，有很多资源可以帮助您。）
我最喜欢的书是查尔斯·佩措尔德的书和亚当·内森的书。 然而，Sells & 的《Programming WPF》第 18 章介绍了这一点。 Griffiths 对该主题的概述非常出色，特别是对以下问题的讨论：我真的需要自定义控件吗？
这里有两篇文章特别值得您看一下（一个，两个）。
MSDN
我同意 Bijington 的观点，即 MSDN 文档非常出色。
博客
在我在上面的论坛部分引用的两篇 StackOverflow 帖子中的其中一篇中，我指着我的“必读”列表上的一组博客。 我特别要指出 Pavan Podila 和 凯文·摩尔。 Kevin Moore 曾经是 WPF 控件的 WPF 程序经理，他有一组很好的控件，称为 WPF Bag-o -有用的技巧，但更重要的是，您可以从中学习的控件。
示例、示例和更多示例
那里只有大量的样品。 几乎太多了！ 我会指出 Family.Show （它是作为 WPF 的端到端参考示例创建的），我会指出 WPF SDK 示例，特别是该部分中的控件自定义示例。
(I apologize in advance for the long post ... there was just so much I wanted to convey ... I hope it helps you.)
This is what we are doing now (migrating a Windows Forms application with heavy use of custom (GDI+) drawn controls to WPF). In fact, my role on the team was to build these GDI+ controls ... and now to build the WPF ones.
I agree with Bijington that making your application completely 100% WPF from the ground up is the way to go ... if you can convince the powers that be to go that route. However, we ourselves are converting our Windows Forms application in-place, taking advantage of the WPF interop capabilities. There are some limitations, but overall it has been an effective approach (and not as frustrating as I would have expected).
What I would suggest is that you take one of your GDI+ controls and build the same control in WPF. And then, when you are finished, throw it away and do it again. You will invariably learn something during the first effort ... and discover that there is a better way to do it instead. I would start with something small ... a custom button is a good place to begin.
Doing the above will give you a taste for what is going to be required for everything else you want to do.
One thing I would warn you about is WPF's learning curve, especially if you are coming from a Windows Forms background ... and especially if you are going to be building custom looking controls. As Abe has mentioned, it is a completely different world. WPF definitely brings a lot of power, but that power comes at a cost of learning how to use it. Abe mentions how custom controls in WPF are 'lookless' and that their 'look' can be provided with a ControlTemplate. This is just one of many ways in WPF to provide custom looking pieces of your user interface.
Let me enumerate some of those additional ways:
In Windows Forms, it was like they gave you a hammer (UserControl) and a screwdriver (Control). However, in WPF ... they have given you the whole toolbox with all 100 tools. And this is part of the reason for the bigger than normal learning curve. However, now you can take that saw that you never had before and use it to saw off the end of a 2x4 instead of using the hammer and/or screwdriver to try and do the same thing.
Resources
(The good news is that there are a lot out of resources out there to help you.)
My favorite books are Charles Petzold's book and Adam Nathan's book. However, chapter 18 of Programming WPF by Sells & Griffiths is really great overview of the subject, and in particular coverage of the question: Do I really need a custom control?
Here are two posts in particular that you will want to take a look at (one, two).
MSDN
I agree with Bijington that the MSDN documentation excellent.
Blogs
In one of the two StackOverflow posts that I reference in the Forums section above, I point to a set of blogs on my 'must read' list. In particular, I would especially point to the blogs of Pavan Podila and Kevin Moore. Kevin Moore used to be the WPF program manger for the WPF controls and he has a nice set of controls called the WPF Bag-o-Tricks that are useful, but more importantly, controls that you can learn from.
Samples, Samples, and more Samples
There are just a ton of samples out there. Almost too many! I would point to Family.Show (it was created as an end-to-end reference sample for WPF) and I would point to the WPF SDK samples and in particular to the Control Customization samples within that section.
开发 WPF 控件的方式发生了范式转变。 您只需定义预期的行为，而不是定义所有行为并寻找控件。
这是迁移到 WPF 最困难的方面。 您的控件类定义行为契约，并公开将用于呈现的属性，并且 ControlTemplate 用于定义控件的外观。
这也是WPF最强大的功能之一； 在将来的任何时候，您的控件的使用者都可以更改其外观，而无需更改其行为方式。 这使得您的控件的主题化变得更加容易。
There is a paradigm shift in how you develop controls for WPF. Instead of defining all the behavior and look for a control, you only define the intended behavior.
This is the hardest aspect of migrating to WPF. Your control class defines a contract of behavior, and exposes properties that will be used to render, and a ControlTemplate is used to define how the control looks.
This is also one of the most powerful features of WPF; at any point in the future, a consumer of your control can change how it looks without changing how it behaves. This allows for much easier theming of your controls.
这实际上是我目前正在做的一个项目，尽管我很幸运能够重新开始。 如果你能做到这一点，我强烈推荐它，显然保留旧系统/控件的核心功能，但重新开始。 从基础开始并了解以前哪里出了问题/正确的地方总是好的。
就我个人而言，我发现 msdn 网站 非常有用，如果不是 stackoverflow 的话一个非常好的获取知识的地方。 如果您有需要，我很乐意为您提供指点。
另外，如果您对数据绑定有任何疑问，可以去这里：
贝亚科斯塔
她已经涵盖了那里的大部分内容。
需要额外说明的是，使用 wpf 相对于 GDI，我们在性能上有了巨大的提高。
This is actually a project i am working on at the moment although I have been lucky enough to be able to start again. If you can do this I would strongly recommend it, obviously keeping the core functionality of the old system/controls but start afresh. It is always nice to start from a base and to know where things went wrong/right previously.
Personally i have found the msdn website extremely useful, if not stackoverflow is a very good place for knowledge. I would be happy to give pointers if you need any.
Also if you ever have any questions about databinding this is the place to go:
bea costa
she has covered most stuff there.
On an extra note we have experienced a huge improvement in performance with using wpf over GDI.