File organization tip for Custom Control authors

Custom controls can be fun to develop. Depending on the complexity of the control it would be a good practice to break it down into manageable pieces. While developing ElementFlow, I discovered such a technique which you may also find useful.

ElementFlow is a fairly complex custom control and there are many interacting pieces in it. Here is a quick listing:

  • 3D setup
  • Handling meshes
  • Animations
  • Viewstates (Coverflow, Timeline, etc)
  • User input handling (Keyboard, Mouse)

Putting all of this logic in the same file (ElementFlow.cs) made it a little cumbersome for me to navigate the file. Ofcourse I could use #region and #endregion to demarcate blocks of code but it was not that appealing. It works great to organize simpler elements like properties, fields, constructors, etc.

A Better way

What I was really looking for was a higher-level logical organization. The answer lied in using Partial Classes. It’s a great language feature and should be exploited :) Most of us know that the Visual Designers in VS use partial classes to keep the code-behind separate from the “designer-vomit”. It keeps our code-behind neat and readable. As control-authors we can leverage this feature to our benefit. To better understand, let me describe the way I used it.

As described earlier, ElementFlow has many logical pieces. Using partial classes, these pieces can be pushed to separate files, keeping the original ElementFlow.cs file pretty short. I decided to organize it into four files:

  1. ElementFlow.cs : contains public-facing properties, constructors and methods. This serves more like a definition of the control.
  2. ElementFlow.3d.cs : contains most of the Viewport3D, mesh-handling logic
  3. ElementFlow.animation.cs : contains creation of Storyboards, manipulating animations, viewstates etc
  4. ElementFlow.input.cs : contains logic to handle user-input

Keeping such a separation has given me a convenient way to see the different parts of my control. In future when I have to expand the functionality I could manipulate one of these files [or create a new partial class]. Adopting a convention for file-naming could be the next step when your organization is primarily into custom control development.

As a side-thought, this post could be corollary to my earlier article on control development.