.Net没有可视组件的组件类 [英] .Net Component classes without visual components

问题描述

我已经创建了许多在其祖先中包含IComponent的.net类。这些类没有可视化元素，需要设计视图;但是，作为组件，它们的默认视图是设计视图而不是代码视图。是否有一些机制可以强制这些项在Visual Studio中双击它们而不是打开无用的设计视图时打开代码视图？如果是这样，请指出我的解决方案。似乎是一个简单的问题，但要么我的搜索功能今天都很弱或者不是那么简单。



提前致谢！

- Marc A. Brown

I've created a number of .net classes that include IComponent in their ancestry. These classes have no visual elements to them that would require a design view; however, as components the default view for them is the design view rather than code view. Is there some mechanism to force these items to open the code view when double-clicking them in Visual Studio rather than opening a useless design view? If so, please point me toward a solution. Seems a simple issue but either my search-fu skills are weak today or it's not so simple.

Thanks in advance!
--Marc A. Brown

推荐答案

在这种情况下，您应该质疑是否需要实现此接口。看看它：它的成员只与处理有关，只是为了在设计师中使用它们：

http://msdn.microsoft.com/en-us/library/system.componentmodel.icomponent.aspx [ ^ ]。



您应该了解该平台基于垃圾收集，因此无需解决大多数对象的最终确定问题。处理机制对于1）具有其父子树的UI的典型分层终结很重要，因此在组件中，2）用于支持回收非托管资源，3）用于支持使用语句 （ http://msdn.microsoft.com/en-us/library/yh598w02.aspx [ ^ ]）。大多数类型不需要任何这些功能，绝对多数。



在您的问题中，我看不出任何典型功能的需要组件。而且，即使其中一些需要使用2-3功能，它也与 IComponent 接口无关。您应该理解，对于通用类型库而言，某些类型的好处并不意味着使它们成为组件。大多数库类型不应该是组件。



最后，（叹息......）我必须说我总是批评过度使用设计师的想法。组件库中可用的非可视组件实际上不应该是组件并在设计器中使用。我从不在设计师中添加定时器这样的东西。很明显，设计师是一种缓慢且高度手动的编程方式。定义一般布局是好的。放置许多细节，特别是重复细节，只会破坏项目的可支持性并延迟开发。非可视组件只会污染设计师的观点。我认为添加它们只是微软和其他一些公司的人为营销炒作。他们向其他公司的非编程代表展示了该产品，并试图创造一种幻觉，使编程简单，可视和无需编码。这一切都不是真的。微软的一个问题（虽然不是很大）是：他们喜欢取悦湖人。我们需要学习如何避免捕获诱饵。 :-)







仅供比较，请参阅我过去的回答与XAML类似的设计师问题：表单生命周期中发生的事件 [ ^ ]。



[结束编辑＃1]







请在下面的问题中查看我的评论，以回复您的评论。实际上，Visual Studio存在某种设计缺陷：如果使用派生自类 System.ComponentModel.Component 的顶级类创建任何文件，直接或间接，解决方案资源管理器表现不佳：它在双击时显示一些无用的设计窗口（但在F7上有正确的代码窗口）。



这不仅非常烦人;一个人可能会意外地将这些组件添加到这个虚假的设计视图中，这只是用虚构的文物污染了项目。



你可以使用一些人工解决方法来避免它。首先，您可以将这些类声明为其他一些类的嵌套类，比如静态类，就像代码范围一样。我不喜欢它，因为代码实际上被不必要的东西污染了;只是想提一下才能理解。



我更喜欢做不同的事情，这更加人为而且不明显，但至少不会改变任何必要的东西。如果更改文件名，则此故障将消失。该文件应以.designer.cs结尾。 （我使用设计师，而不是设计师，与自动生成的文件创造一些差异。）



实际上，我经常使用它来添加额外的部分部分表单类。如果某个表单文件被命名为MyForm，则会创建文件MyForm.cs和MyForm.Designer.cs。如果我在一个单独的文件中为这个类添加一些额外的部分，这个文件也会显示这个冗余的设计器页面。正如我所说的那样，问题就消失了，例如MyForm.Setup.designer.cs，依此类推。



我理解这个解决方案是一个解决方案有点难看，但你能提出什么建议？不要改变Visual Studio或乞求微软改进设计，我希望... :-)

至少它对我来说很顺利，所以我也可以为你提供建议。



[结束编辑＃2]

-SA

In this case, you should question the need for implementing this interface. Look at it: its members are only related to the disposing, and only for the purpose of using them in the designer:
http://msdn.microsoft.com/en-us/library/system.componentmodel.icomponent.aspx[^].

You should understand that the platform is based on Garbage Collection, so finalization of most objects does not need to be addressed. The disposal mechanism is important for 1) hierarchical finalization typical for UI with its parent-child trees, hence in components, 2) for support of reclaiming of the unmanaged resource, 3) for support of the using statement (http://msdn.microsoft.com/en-us/library/yh598w02.aspx[^]). Most types don't need any of these feature, absolute majority of them.

In your question, I see no indication of a need in any of the features typical for components. And, even if some of them require the use of the features 2-3, it is not related to IComponent interface. You should understand that having some types good for a universal type library does not mean making them components. Most of the library types should not be components.

And finally, (sigh…) I must say that I always criticized the idea of overusing the designer. Non-visual components available in component libraries should not really be components and used in the designer. I never add such things as timers in a designer. It's apparent that the designer is a slow and highly manual way of doing "programming". It is only good to define general layout. Putting many detail, especially repeated, only kills supportability of the project and delay development. Non-visual component only contaminate the designer's views. I think adding them is just the artificial marketing hype of Microsoft and some other companies. They demonstrate the product to non-programming representatives of other companies and try to create an illusion that it makes programming "easy", "visual" and "without coding". This is all not true. One problem (not very big though) of Microsoft is: they like to please the lamers. We need to learn how to avoid catching the bait. :-)



Just for comparison, please see my past answer on the similar designer problem with XAML: Event Occurring in the Form Life Cycle[^].

[END EDIT #1]



Please see my comment to the question below, in reply to your comment. Really, Visual Studio has some kind of design defect: if you create any file with the top-level class derived from the class System.ComponentModel.Component, directly or indirectly, Solution Explorer behaves in inadequate way: it shows some useless design window on double click (but correct code window on F7).

This is not just highly annoying; one can accidentally add components to this fake "design view" which just contaminate the project with fictitious artifacts.

You can use some artificial work-around to avoid it. First, you can declare these classes as nested classes of some other, say, static class serving just as the code scope. I don't like it, because the code is actually contaminated with something unnecessary; just wanted to mention it for understanding.

I prefer doing different thing, which is even more artificial and not obvious, but at least does not change anything essential. If you change the name of the file, this glitch will disappear. The file should be ended by ".designer.cs". (I use "designer", not "Designer", to create some difference with auto-generated files.)

Actually, I often use it for adding extra parts to partial form classes. If some form file is named, say, "MyForm", it creates the files "MyForm.cs" and "MyForm.Designer.cs". If I add some extra part for this class in a separate file, this file will show this redundant designer page, too. The problem disappears, as I names it, for example "MyForm.Setup.designer.cs", and so on.

I understand this work-around solution is a bit ugly, but what else could you suggest? Not changing Visual Studio or begging Microsoft to improve design, I hope… :-)
At least it works smoothly for me, so I can advise to for you, too.

[END EDIT #2]

—SA

烦人不是，但解决方案很简单。

Annoying isn't it but the solution is very simple.

[System.ComponentModel.DesignerCategory("")]
public class MyComponent : Component {}

完整的属性名称是必需的，你会发现 [DesignerCategory （）] 并且System.ComponentModel的using namespace指令将不起作用。



Alan。

The full attribute name is required and you'll find that [DesignerCategory("")] and a using namespace directive for System.ComponentModel won't work.

Alan.

这篇关于.Net没有可视组件的组件类的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！