(1 item) |
|
(1 item) |
|
(5 items) |
|
(1 item) |
|
(1 item) |
|
(2 items) |
|
(2 items) |
|
(4 items) |
|
(1 item) |
|
(6 items) |
|
(2 items) |
|
(4 items) |
|
(1 item) |
|
(4 items) |
|
(2 items) |
|
(1 item) |
|
(1 item) |
|
(1 item) |
|
(1 item) |
|
(1 item) |
|
(1 item) |
|
(1 item) |
|
(1 item) |
|
(2 items) |
|
(2 items) |
|
(5 items) |
|
(3 items) |
|
(1 item) |
|
(1 item) |
|
(1 item) |
|
(3 items) |
|
(1 item) |
|
(1 item) |
|
(2 items) |
|
(8 items) |
|
(2 items) |
|
(7 items) |
|
(2 items) |
|
(2 items) |
|
(1 item) |
|
(2 items) |
|
(1 item) |
|
(2 items) |
|
(4 items) |
|
(1 item) |
|
(5 items) |
|
(1 item) |
|
(3 items) |
|
(2 items) |
|
(2 items) |
|
(8 items) |
|
(7 items) |
|
(3 items) |
|
(7 items) |
|
(6 items) |
|
(1 item) |
|
(2 items) |
|
(5 items) |
|
(5 items) |
|
(7 items) |
|
(3 items) |
|
(7 items) |
|
(16 items) |
|
(10 items) |
|
(27 items) |
|
(15 items) |
|
(15 items) |
|
(13 items) |
|
(16 items) |
|
(15 items) |
By default, when you open a source file in Visual Studio .NET it shows a design view if it can, whether it's useful or not.
Often it is useful - for example, the design view for a class derived from System.Windows.Forms.Form
allows WYSIWYG editing of the form layout. But it sometimes opens a design view that offers no benefit.
For example, there is a design view for any class derived from System.ComponentModel.Component
.
To be fair, this view has its uses: if your class has an InitializeComponent
method, the design view lets you
populate that by dragging non-visual items from the Toolbox onto the design surface. You can then select those items and
edit them in the Property grid.
That's all perfectly reasonable. What I object to is when I've written a class which derives from
System.ComponentModel.Component
, but which doesn't have an InitializeComponent
method. It's true that the design view will happily add one for me if one isn't present. (Although it won't add code to the
constructor to call it.) But I usually find that if I have a Component
-derived class that doesn't have an
InitializeComponent
method, it's because I don't want to use the design mode to edit it - it just contains
some code. (Custom controls are the example I keep running into, but I've hit this with non-visual components too.)
Of course you can just change the VS.NET default for how it opens files. Simply right-click on the file in the editor and choose 'Open With...' from the menu. Select CSharp Editor (or VB Editor, or whatever you preferred language is), making sure you choose the one without 'Form Editor' in the name. Then click the 'Set As Default' button. VS.NET will then default to using the code editor from now on.
The problem is, it will do it for everything. What if you want it to carry on opening the design view for those files where this is useful, and only open a code view for specific files?
Well you can place an indication in a file that will cause VS.NET to always default to a particular editor for that file,
regardless of what the current VS.NET default may be. Simply apply the
System.ComponentModel.DesignerCategory
attribute to the class. For example this class:
[System.ComponentModel.DesignerCategory("Code")]
public class MyComponent : System.ComponentModel.Component
{
...
}
will always open in the Code view by default, even if VS.NET is configured to open the design view by default. (Of course, the user can always explicitly choose which view to open by right-clicking on the item in the Solution Explorer. This simply affects what happens when the user double-clicks.)
Note that you must use the attribute's namespace-qualified name, even if you have a using
statement importing the System.ComponentModel
namespace - VS.NET only honours the
DesignerCategoryAttribute
if you write out the fully qualified class name.