Click here to Skip to main content
15,891,184 members
Please Sign up or sign in to vote.
0.00/5 (No votes)
See more:
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
Posted

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. :-)

[EDIT #1]

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]

[EDIT #2]

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
 
Share this answer
 
v4
Comments
Marc A. Brown 17-Apr-14 17:46pm    
None of which answers the question. There's either a way to do it or there isn't. Whether nonvisual components are a good idea or not is immaterial. If what I'm doing involves extending a class that implements IComponent, I can't really help that it's a Component, I would just like to determine whether there's a solution to my issue (which is admittedly a matter of convenience rather than necessity).
Sergey Alexandrovich Kryukov 17-Apr-14 17:50pm    
I understand. No, this is not immaterial, but I think I know what I missed and what's your problem. This is a kind of Visual Studio design defect, worse than what you mentioned, because one accidentally could try to use this useless design view, filling in totally irrelevant components.

Please give me a little time, I'll describe the workaround I found.

—SA
Sergey Alexandrovich Kryukov 17-Apr-14 18:10pm    
(Sigh...) Please read about this work-around solution in the updated answer, after [EDIT #2]. Good or not, it really works.
Is your question answered now?
—SA
Marc A. Brown 18-Apr-14 10:18am    
And now I feel like a complete idiot. Digging back to my parent class I see that I *did* inherit from Component. I have no idea why I would've done so and since it's library code I'm fearful of changing it (removing Component and implementing IDisposable) because I'm not sure that doing so wouldn't create breaking changes in projects that use it (not all of which are mine). In any event, I tested your solution and it does work (as does the solution below from Alan).
Thanks!
Sergey Alexandrovich Kryukov 18-Apr-14 10:36am    
You are very welcome.
—SA
Annoying isn't it but the solution is very simple.
C#
[System.ComponentModel.DesignerCategory("")]
public class MyComponent : Component {}


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

Alan.
 
Share this answer
 
Comments
Sergey Alexandrovich Kryukov 17-Apr-14 23:30pm    
I just tested it, it works. Thank you for sharing.

However, I don't like you: it contaminates source code itself with totally irrelevant artifacts. If you supply your library with such thing, how will you explain it to your user? Maybe, its a matter of taste, but I prefer cleaning code. Adding some redundant line of code just to cover some VS stupidity is too much to me. I really prefer file naming trick. It's not good, too, but at least file name is not related to the code...

I really appreciate your contribution, but...

—SA
Marc A. Brown 18-Apr-14 10:19am    
Nice solution. Thanks! This is what I was searching for yesterday but couldn't find.

This content, along with any associated source code and files, is licensed under The Code Project Open License (CPOL)



CodeProject, 20 Bay Street, 11th Floor Toronto, Ontario, Canada M5J 2N8 +1 (416) 849-8900