VB400,<br><br>I have done this more times than I care to remember. There are only a few 'tricks' to remember.<br><br><b><u><font color=red>ALL</font></u></b> VB 'modules' are - just plain old text files.<br><br>Class modules have a few lines at their start which VB does not show. You can get these by using a text program - NotePad is good for this. Open NotePad, use it to opne any VB Class file, copy the lines which you don't see in the class module when you open it in VB. Save these to some text file ('clsHdr.Txt').<br><br>For most groups of 'classes' there are functions which are the same for each class (using a data access class as an example, open/close; first/last; next/previous; LtKey/LeKey/EqKey/GtKey/GeKet; ...) For these, I generally create the prototype of the class and just copy these functions to a text file.<br><br>Additional Functions are unique to the Class - even within the group (again, using a data access class, these would represent the individual field elements of the class. For these, I generally make a small MDB database which list each "Type" (dataset/table), the field name and characteristics (type/length ...). by getting each field of each dataset I "build" the UDT which represents the class as a UDT - again as a text file.<br><br>When the various 'constant' parts of the Class module are some where on disk as text file(s), I have a VB project/module which accepts the a token representing the name of the class, opens the various text files, reads them, and writes them back to disc as a single file with the extension ".cls".<br><br>Of course, each of the parts needs to be written in a specific order, and the variable parts need to be inserted in their proper "place". Again, using the data access model, most of the variable parts and the property Get/Let procedures. These are basically the field elements of the UDT, and are normally vert short (mine are mostly three lines;: <br>Declaration <br> Statement <br>End Function.<br><br>The declaration is just the Function Get ¦ Let (for the Let, the var passed to the function) For the Get, the var type passed from the function.<br><br>The statement obviously just passes the var info to ¦ the class to the outside world.<br><br>End Function is just end function.<br><br>The var and it's type are taken from the small MDB table noted earlier.<br><br>It is possible to bypass some of this by having the skeleton of the fixed parts in place as a class module with some embedded tags to show where to place the various variable parts and just do that. My experience has been that I need to make as many changes to the fixed parts as the variable one(s), and it is just as easy to do it in the text file as the skeleton class, so I do not maintain the skeleton class.<br><br>Also, for most of the classes I generate in this manner, hter are a few pieces (KeyWords) which are changes from Calss to Class - enven though they are in the "fixed" part. For these, I just embed a KEY_WORD in the text file. When the text file ir read in, I parse for the KEY_WORD and replace it/them with the class specific repalcement word. In (almost?) cases, these Key_Word(s) are just the class name of some variation thereof.<br><br>MichaelRed<br>There is never time to do it right but there is always time to do it over