重写标准控件，如编辑，组合等？ [英] Rewrite standard controls like edit, combo, etc?
问题描述
我有一个自定义控件：它是托管代码，它是子类System.Windows.Forms.Control。
我想添加像编辑框，选择列表，组合框，单选按钮等等到此控件上的位置。一个简单的方法是简单地将这些类的实例添加到Controls集合，以便它们成为子控件。
将它们添加为子控件可能会创建一些微妙的问题，例如：
当我使用IE7显示 http://www.tizag.com/htmlT/htmlselect.php （例如），其中包含组合框等，当我在使用Spy ++侦探IE7时，我看到只有一个没有子级的窗口/控件实例（其类名为Internet Explorer_Server）。
我猜这意味着在IE7中，一个组合框内置于IE7控件本身，而IE7不使用标准控件作为子控件。
问题：
- 是否最好将标准控件作为自定义控件的子元素重用，或者在自定义控件本身中重新实现标准控件的功能？
- 您有任何需要分享的警告（警告），与这两种情况相关吗？
- 如果我想在自定义控件中重新实现标准控件的功能，
如果这样的代码已经存在，我不知道如何实现这个功能搜索它（我的搜索查找，例如，所有者绘制组合框和标准组合框的扩展）：可能很少人从头重新实现标准控件？
编辑
我发现了一个半相关的问题：如何使控件看起来像ComboBox与Visual样式启用？
是的，Internet Explorer使用Windows主题API绘制控件。您也可以使用System.Windows.Forms.VisualStyles命名空间中定义的类型。
IE团队这样做是为了避免有这么多控件的性能问题，每个接收窗口消息，在屏幕上一次。例如，查看这个StackOverflow.com页面，我看到30-40个链接标签控件，10个按钮等，20多个标签等。
Zune软件是.NET托管代码，也使用自定义控件;如果你试图在任何控件上使用Spy ++，你会看到他们不是真正的Win32控件。你可以在Zune软件上使用Reflector来查看他们正在做什么。如果我回想起来，他们使用Zune软件中包含的自定义管理的UI框架。
至于从头开始重写这些控件，我想有一吨的工作要做。这听起来比真的更容易。
I have a custom control: it's managed code, which subclasses System.Windows.Forms.Control.
I want to add things like edit boxes, selection lists, combo boxes, radio buttons and so on to places on this control. An easy way to do this is to simply add instances of these classes to the Controls collection, so that they become child controls.
Adding them as child controls might create some subtle problems, for example:
I have scrollbars on my control which appear to scroll the contents of the control (the contents are bigger than the control itself); when a child control is near the edge of the screen then I'd like to half-display (i.e. clip) that child (i.e. to have half of it located off the edge of the physical screen), but a true child control cannot be located outside the border of its parent.
Are there other potential problems?
When I use IE7 to display http://www.tizag.com/htmlT/htmlselect.php (for example), which contains combo boxes etc., and when I then use Spy++ to spy on IE7 when I'm doing that, I see only a single Window/control instance with no children (whose class name is "Internet Explorer_Server").
I'm guessing this means that in IE7, the functionality to render a combo box is built in to the IE7 control itself, and that IE7 does not use standard controls as child controls.
Questions:
- Is it better to reuse standard controls as children of a custom control, or, to reimplement the functionality of standard controls within a custom control itself?
- Do you have any caveats (warnings) to share, related to either scenario?
- If I wanted to reimplement the functionality of standard controls within a custom control, do you know of any existing code (which implements this functionality) that I could re-use?
If such code already exists, I don't know how to search for it (my searches find, for example, owner-draw combo boxes, and extensions to standard combo boxes): perhaps few people reimplement the standard controls from scratch?
Edit
I found a semi-related question: How to render a control to look like ComboBox with Visual Styles enabled?
Yes, Internet Explorer draws the controls using the Windows theming APIs. You can do this too using the types defined in the System.Windows.Forms.VisualStyles namespace.
The IE team did this to avoid performance problems of having so many controls, each receiving window messages, on screen at once. For example, looking at this StackOverflow.com page, I see 30-40 link label controls, 10 buttons or so, 20+ labels, etc.
It should be noted the Zune software, which is .NET managed code, also uses custom controls; if you try to use Spy++ on any of the controls, you'll see they aren't real Win32 controls. You may use Reflector on the Zune software to see exactly what they're doing. If I recall right, they're using a custom managed UI framework that's included in the Zune software.
As far as rewriting these controls from scratch, I think there's a ton of work to be done. It sounds easier than it really would be.
这篇关于重写标准控件，如编辑，组合等？的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！
