As an experiment I've decided to try splitting Form code (event handlers and the functions they use) across a number of partial classes for my main Form, essentially placing the code supporting a control in its own file. The C# code (.cs) files are created by adding new (empty) code files to the project. I add the namespace and partial class definition the same way the .Designer.cs files do. Everything compiles, runs and functions just fine, as expected. When I use the Forms design UI to add a new Control event handler it places the generated code in the main Form.cs file, as expected. I move the handler to the proper partial file and everything continues to function properly. But the Forms design UI doesn't appear to be able to locate the event handlers in the secondary partial class files. If I use the UI to try to navigate to an existing event handler, e.g. by double-clicking an event in the properties window, it will instead incorrectly navigate to some unrelated location in the main Form.cs file. (Apparently near where it thought it put the code?) Worse still is that when I now create a new event handler using the design UI it will also create an apparently random number of event handler stubs for a subset (not all) of the handlers that reside in the secondary partial classes. These will result in "multiple definition" errors for these handlers when the project is compiled.
So perhaps I'm missing some way to make these partial class code files subordinate to the main Form.cs file so the designer can find the event handlers? But I've found no UI mechanism to create them that way, nor will the UI allow me to drag these files under the main Form.cs file. But the .Dsigner.cs file is there, so there must be some way to establish this relationship. Though that in and of itself might not solve the problem. Certainly the designer could be corrected to find these handlers, e.g. via reflection, since the compiler has no problem making the connections.