局部类并双击控件

Question

If I have a function in a partial class (let's say I have 'Button 2' click handler) and then double-click on 'Button 2' in the Form designer, Intellisense (or whatever is in charge now) always throws me to the 'Form1.cs module' (at an ill-defined or blank line), not the new partial class module 'Button2.cs'. Double-clicking on 'Button1' does the 'correct' action.

For example:

In 'Form1.cs':

namespace test01
{
    public partial class Form1 : Form
    {
        public Form1()
        {
            InitializeComponent();
        }

        private void button1_Click(object sender, EventArgs e)
        {
            MessageBox.Show("Button 1 pressed");
        }

    }
}

In 'Button2.cs' (a public partial class):

namespace test01
{
    public partial class Form1 : Form
    {


        private void button2_Click(object sender, EventArgs e)
        {
            MessageBox.Show("Button 2 pressed");
        }
    }
}

This is something I've seen in VS2008 and now in VS2010 and there is no obvious way (to me) to resolve it.

Any help out there?

Answer 1

That's because you are designing the form , not the button. The designer expects that (by convention) all of your event handlers for the controls on the form are located in the form's source code, not the button's source code. This makes sense when you consider that (generally) button2.cs probably should define a class called button2 , not an instance of the class Button whose Name property happens to be "Button2".

EDIT:

Partial classes are designed for a very specific purpose- when a class is generated by a designer or other code generator, it is typically unsafe for a developer to edit that class by hand (because the code generator will come by later and overwrite the file, including the developer's hand-written parts). Partial classes allow a class to be split across two files- one is generated (by the designer in this case) and one is meant for hand-written code. Because the class is defined as "partial", the compiler knows that other parts of the class may be defined in other files.

For a project that has several different areas of functionality like you describe, I'd organize those into classes that were unrelated to the UI (so that the functionality can be independently unit tested), and then call them from UI classes as needed. You should look into concepts like the Model-View-Controller or Model-View-ViewModel design patterns for an idea of how this works.

A folder structure like this wouldn't be unreasonable as a starting point:

Root
|-GUI           // Contains folders related to GUI elements
| |-Forms       // Contains your forms
| |-Controls    // Contains any custom controls
|-Common        // Contains folders for common functionality
| |-IO          // Contains classes relating to I/O
| |-Diagnostics // Contains classes relating to diagnostics
|-Logic         // Contains classes folders to specific business use cases
  |-UseCase1    // Contains classes folders to use case #1 (use a better name, obviously)
  |-UseCase2    // Contains classes folders to use case #2