Template Design

This is a fairly general question, however, I am trying to work out the pros and cons of the different ways of developing template sets.

Currently I have a master template that sits in the Startup folder and contains all the code that is used to populate the files created from the Workgroup templates. The workgroup templates are layout templates only and don

Re: Template Design

Karen,

We've recently moved to a somewhat similar setup, where global code sits in a global template in the startup directory, and code specific to individual templates sits in the individual templates. In each of the individual templates, we set a reference to the global template. This seems to be working fine, and developing with it is not really harder once you get used to a few working practices:

The directory structure in your development environment should parallel the directory structure in your live environment - that is, global template in the startup directory, and workgroup templates in the assigned workgroup directory. This is one way to help ensure that the conditions you're developing in are going to be the same as the conditions the templates are run in.

This doesn't mean you're stuck with only one directory structure in your development environment; for instance, since we still support both Word 97 and Word 2000, I've got two different development directory structures, and I swap the settings in Tools>Options>FileLocations to either the 97 or 2000 locations as needed (this switching can also be effected via a macro, but you'll need to store this in your Normal.dot so that you can run it from either environment).

As far as being able to see the code in your global template if it's in the Startup directory, that's not really a problem - just open the global template while you are working on your workgroup template - if you are for instance stepping through code in the workgroup template and a call is made to a procedure in the global template, you should be able to see the code run in both open templates. To make it easier to open the global template in your startup directory (that is, to spare you having to browse to it all the time), just put a button on a toolbar, that runs a macro to open the global template. In fact you can create your own custom development toolbar with buttons for shortcuts to do all of the above - put it in your Startup directory, and you'll always have it available.

Application.Run is a less desirable solution, because it is very difficult if not impossible to pass parameters.

Just a few tips from having been there (recently <g>). If you have any specific issues that arise in setting up your template environment, I'm sure they'd be of interest if you post them here.

Re: Template Design

Hi Karen,

My preference is to have shared code in the master global template and to have templates that have their own specific coding as needed. I use application run.

If I have code that is common to one (large) class of documents (pleadings?) I may have a separate global template for that which is loaded as needed by the pleading templates. I generally don't have it unloaded by the template because I haven't worked out the code to be sure it isn't being used by another template.

I open the globals when I need to reference their code when working with other templates. I'll be using Gary's suggestion to develop a separate template development add-in with toolbars & macros.

Re: Template Design

Hi Gary, I see the logic in what you're saying. I'm still reluctant to commit to that design environment - I work on templates for many different legal firms and other organisations and don't want to use *my* Startup directory to store client files. I have in the past set up a client folder with subfolders for Startup and Templates, but I still have to change my File Locations and that means I can't then use my own templates when I need to create a document for our company. This can happen while I am in the middle of development of a set of client templates.

Re: Template Design

Karen

I suggest you examine the reason you need so many templates?

I avoid the creation of a huge number of templates by combining multiple autotext entries all in the same .dot file. This means that the same set of related macros, toolbars, styles etc are available when you open the template and the user just has to pick which boilerplate text they want added to start the new file. You can use a macro to pull the list of available autotexts into a userform that is called with AutoNew so that non-programmers can add boilerplate as they need to.

With this method I only need
* one template for various reports as they all use the same layout, styles, cover page etc
* one template for forms
* one for correspondence (letters, memos, faxes)
* various other bit player templates.

Re: Template Design

Oh dear, that opens up a whole new can of worms!! The templates are all highly automated, for instance a letter does different things than a settlement statement (this one has many calculations). My users fill in information into a dialog box for the specific template and the template and code creates, names and saves the document.

Your idea has merit, although personally I hate autotext and would rather use insert file to put in boiler plate text as I find separate files easier to maintain, especially when it has to be maintained by the users. However, with a massive rethink I could restructure the template design.

I think a need a *month* to think about the options, pros and cons, and then start from scratch!!

Re: Template Design

Hi Karen,

Instead of putting them in your startup folder, why not use macros to switch Add-Ins in and out. That way you can have the client's setup when working on their documents and switch back to your own environment at the click of a button. Simply add a folder and a button on your development toolbar for each new client.

For simplicity's sake, I would suggest that one macro unload all Add-Ins and then load all Add-Ins in a particular folder. You would want to have a shortcut to your development add-in in each of the client folders or add that as a separate command at the end of your switch to the client environment.

Re: Template Design

<hr>Application.Run is a less desirable solution, because it is very difficult if not impossible to pass parameters.<hr>

A slight disagree. I can pass parameters; but (I think) it's equivalent to a "byvalue"- ie, I can pass them to a routine, but I can't get values back. (I haven't needed to get a value back, a function might be able to do it).

Re: Template Design

We've gone for an approach similar to Gary's- but with an approach which might suit your environment.

We have templates in a directory structure completely outside the user/workgroup templates environment. But we have a custom button which calls up a user dialog allowing the choice of a new form.

The button is made available via an add-in. It is easily changed for different customers (the file location could be via an ini file). Several hundred templates are made available, organised into major categories and sub categories. The user can add to a favourites list within the "mini-application", or can search through all folders for a template.