Maybe I should encapsulate each of the controls to a user control, and then make a virtual ActiveX control (no visual interface) to organize these controls into a united thing.
- Create a ActiveX DLL (not control)
- Define a Interface for the form in
the DLL - Move all your logic into one or more class in the DLL and have the routines interact with the form through the interface
- Implement the Interface in the form
- One initialization of the app have the form register itself with the ActiveX DLL
This will effectively eliminate copy and paste between the different apps.
For example for my metal cutting application I have a Shape Form, a Shape Screen class, and a bunch of shape classes. Two of the methods of the shape class are DrawScreen which has a parameters of type ShapeScreen, and GetValues which also has a parameter of type ShapeScreen.
DrawScreen uses the method of ShapeScreen to setup the entry screen and Shape Screen setup the Form through the IShapeForm interface. The GetValues uses Shape Screen methods to get the entered shape values which in turns uses the IShapeForm to get the values from the form.
This setup proved useful when we had to develop different shape entry forms in response to customer requests. The new form just implemented the IShapeForm interface and the rest of the software was untouched.
It looks like what you have is a view, domain logic, and data. Your major problem I foresee is item two, it is not static in appearance and logic from app to app. Maybe what you need is two separate controls? Left panel and right panel. The right panel probably is going to implement some type array of controls, since they are not going to be static.