A helper function-such as bFileExists-is an obvious start for your template's library, but so too are the less obvious ones such as ExtractFileName, ExtractPathName, and AppendSlash. At first you might find it hard to think of helper functions to write. You should be able to find a good selection by looking through existing applications. I'm sure you will find many more candidates this way. Looking through existing applications can also help you to identify code that is duplicated between applications and therefore might warrant inclusion. Another way of identifying code for your template is to use a code analyzer on a few of your existing applications. This will help you to identify the routines that are receiving the greatest number of hits, and therefore may prove more useful in template code where you can more easily optimize them.
Common forms can be a real asset to an application. The Common Dialog control is a classic example of a common form. A progress form, About Box, and Message Box are just some of the common forms you can create. Common forms will give your applications a more standard appearance, and again you will not end up with many implementations of the same functionality. A common application MDI form should not be overlooked either. Having such a form will allow you to pre-create the standard menus, such as File, Edit, Window, and Help. Again, this is the type of code that is a bit of a chore to write for each different application.
Creating Microsoft ActiveX components can be a powerful way of enforcing business rules. Many applications within an organization will need to access a common set of business rules, creating a uniform look and feel. For example, you could create an ActiveX control that wraps your favorite grid control, and build additional functionality such as allowing the user to cut and paste rows of data. Centralizing these rules into an ActiveX server makes sense. That ActiveX server can then be considered base code.