I did something similar to this with the Energy company I worked for but not to the extreme of dll, bas, reference, versioning checking (which I have to agree with georgev on bogging down a project with unneeded modules to do this.) Plus, these "templates" that I created were specifically made for the Energy company and the type of work they did. But regarding centralizing things - YES. You should always centralize things when possible. Code to check other code type stuff though or code to load other coding modules...(I'm not a big fan of this philosophy.)
For my example, I had a "template" unbound form customer mdb which had all the modules, functions, etc..that I needed. I then used that template to construct the different energy star programs around (since the customer database was centralized and each energy star program was "modulized" to take into account that each one tracked different things.) Then I also had an "import" template for importing files and an "export" template, a "report" template, a "security" template which had the security forms, etc...
When I then constructed a new energy star program, I put the pieces together on what I needed, importing items from the other "templates".
"BUT" - this all geared around energy star programs and the Energy company. The customer template that I had designed for the Energy company could not be used "as is" for any other business and although I could use ideas from that template, I would need to re-do most of the stuff if I were to use that template for another company which in essence would take more time modifying versus if I started a new customer interface from scratch for that company. Although an "import" type template and some of the other templates can more easily be tweaked from a somewhat standardized template which I'd import and then tweak.
I've personally devoted most of my time collecting what I call "snippets" of code which do certain things and then if I need to do something, I import that snippet and minorly tweak it to work for the purpose intended. The snippet might be a module, collection of modules, or a specific function to do a specific task. An example is the "GetUser" snippet (in the code bank), where I'll utilize that piece of code in the construction of a new mdb to get the users loginID (which entails a module and a function). After many years of collecting stuff like this, I usually find myself taking a piece of code from one application, another piece from a different application, importing modules from another application, a form that I liked from another, etc...to build a new application.
Things like a splashscreen and other forms though you'll find will always change as you eventually get sick of using the same splashscreen or form in each mdb and end up finding the desire to design a "new look" with each new mdb (or due to the requirements of the new mdb). Having a collection of a dozen different splashscreens or a dozen different report type forms you can choose from is something to consider verses trying to stick with the same type of form which probably will need modifying and look different in your next application.
Keep in mind that any templates you design for the company you're currently working for, will most likely need to be revised for another company you may eventually work to the point that you may wonder if it wouldn't have been easier to start from scratch and just import the necessary pieces of what I call coding "snippets." By the way, there is a coding snippet to check for the current references. Again though, as georgev pointed out, would I have this snippet in every application I designed? - probably not as there are dozens and dozens of snippets which would be nice things to have in every application but I'd rather not bog down that application with every one of them and have to troubleshoot putting them all in one kettle.
Crude...I got long-winded again...sorry about that. Thanks for bearing with me and I hope this helps.
Anyway, as far as samples go, take a gander at the code bank in this forum. There's plenty of examples to look at which will keep you occupied for many, many hours.
Last edited by pkstormy; 04-25-08 at 15:43.
Expert Database Programming
MSAccess since 1.0, SQL Server since 6.5, Visual Basic (5.0, 6.0)