Code Libraries

[GBalcom]

I've been researching building a code library for reference in more than one project. For me, this is appealing, because I have several classes that could be used within several apps. Does anyone do this? Are there any caveats with this approach I should be aware of?

 

[Ranman256]

I have different modules:
ModFiles, all my file procedures.
ModExcel, all excel procedures.
Etc...

Then I just import the modules I need into my working app.

 

[The_Doc_Man]

I once had something like ten libraries - Excel, Word, Outlook, special math, file system object operations, audit and event logging, string parsing, security functions, special control handling, and a list of Windows functions that mapped named calls to specific entry points in a .DLL file. If my project performed any of those functions, I just dropped the pre-built module into the project wholesale. Then if something special came up, I put that into a project-specific general module and that way kept the other general modules almost "pure."

I took it farther than code libraries. I also had form templates for which a lot of events were pre-defined with VBA code for events _Load, _Open, _Current, _Unload, _Close, _BeforeUpdate, and maybe a couple of others. I also had command buttons with _Click events for Help, File Error Report, Commit, Cancel, Create, Remove, Reset, and Close

Granted, the templates only provided frameworks, and sometimes I had to just remove one of the template items because it had no particular value in the specific form (perhaps because it was unbound and thus could never be current, for one example.) But by having a pre-defined template, I spent a few hours up front and then saved those few hours for each of 50 forms. Oh, I still had to customize each form for the data type, add controls to show bound items - and some computed items as well. But my forms always had infrastructure that was easy to manage because I didn't have to re-invent the wheel every time a new form requirement came up. It got to the point that I had three templates - one for normal forms, one for read-only forms (allowed you to examine but not change items that by site rules could NOT be changed once written, e.g. audit trails), and one for specialized help forms that would pop up when you hit the Help button.

Anything you do ahead of time, even if you had to go back and customize parts of it for your specific project, would be something you can spend less time in implementing. Do that often enough and your projects suddenly look better and are MUCH quicker to bring up for initial use. Makes you look like a genius when the truth is, you are just preparing for a moment when you will need all of that stuff. And by having templates, you guarantee a "look and feel" that makes everything consistent in appearance.

 

[GBalcom]

Sorry guys, I should have been more specific. I'm currently dropping in things wholesale like I think both of you are suggesting. In the back of my Access 2010 programmers reference by Wrox (Page 1106 for those of you that have it), they mention that you can add a reference to your own code library (.accdb or others). The gain I think you may get is the code maintenance. But I don't know of the down side (If there is one).

 

[The_Doc_Man]

The only down-side I have EVER found to using templates is that you need to determine the "look and feel" you desire up front. Before you start implementing anything project-specific, you need to tend to your templates. Like, add logos, titles, borders, backgrounds, watermarks, etc., and remove items that don't apply to the project. But after that, you are usually ready to hit the ground running.

As to the code libraries, with a split database the FE file doesn't get very big unless you have localized FE tables for work space. So there was no major down-side to this approach even if you weren't initially intending to use EVERY entry point in the Word library or whatever. Code bloat isn't NEARLY so bad as bloat caused by active table manipulations. And of course, for code, if you don't call it, it won't mess you up.

 

[CJ_London]

Like Doc and Ranman, I have a number of table, code and form/report templates, but I tend to import them into one project rather than keep in a separate library to be referenced at runtime. I support external clients rather than providing internal support/resource. I used to do separate libraries on the basis of change once, change everywhere, but found that this became an administrative nightmare tracking who has what module and have they installed it.

So my view is if you are providing internal resource, you can keep the modules as separate libraries, but if providing external support, copy them into the module.

 

[GBalcom]

I used to do separate libraries on the basis of change once, change everywhere, but found that this became an administrative nightmare tracking who has what module and have they installed it.

So my view is if you are providing internal resource, you can keep the modules as separate libraries, but if providing external support, copy them into the module.

Thanks CJ, that's what I was wondering. I definitely don't want to create anymore administrative work. I believe I'll just continue importing modules into the current project as I need them.

 

[Scott_Hall]

I know what you are referring to GBalcom. I put a code database into play and it has saved me some serious time, as well as ensuring that updating any shared functions is easy and consistent.

 

[MarkK]

I have a very significant code library that I set a reference to in most projects. It provides tons of services to an application that I'm instantly able to deploy and reference in my code. I try and remove anything from an application that is not specific to that application, and instead add it to the library.

To solve the versioning problem, I release the next application version and library version as a pair.

 

[Scott_Hall]

That is exactly what I do as well.

Also, I like having that Code Library always compiled to squeeze every last drop of performance that I can.