Tek-Tips is the largest IT community on the Internet today!

Members share and learn making Tek-Tips Forums the best source of peer-reviewed technical information on the Internet!

  • Congratulations biv343 on being selected by the Tek-Tips community for having the most helpful posts in the forums last week. Way to Go!

Access/Print Code

Status
Not open for further replies.

XTnCIS

Programmer
Apr 23, 2002
57
US
I have recently posted a question about producing programmer documentation and came to conclusion that either the future programmer can review the code on the computer, or I am going to have to do some additional programming to get code printed in such a way as to make it useable (i.e., loops outlined, procedures/functions indexed…)

I know about the documentation wizard in Access, but have found it leave something to be desired.

My program has about 2300 lines of code, which of course doesn't include the properties on the 34 different forms that play a real part in the functionality.

Although I have the code lines documented and indented, nested loops can be hard to follow (especially when they are long and my call procedures/functions) and I'm looking for the best way to provide what may be needed to whoever gets the happy job of maintenance on my program.

So the Question is:
1) Does anyone have any additional feedback on what has been the most helpful maintenance documentation for a program about this size.

2) If I go the route of writing a program that will capture the code and properties and formatting/indexing them (which I doubt I'll have the time to do), Can anyone point me in the right direction for pulling the code pages and properties from a form 'in-code'.

Thanks! Tek-tips has been a great resource!
XTnCIS
 
There are ways you can search through your modules to extract whatever you want (see module object in on-line help). For example, procedures that reside in my library, that can be called by other developers, always contain a header page describing things I need to know about the function/sub. Like, author, purpose of routine, revisions, etc. The first line of my header begins with '+. A one line description of the function begins with '$. The last line of the header begins with '-.

Like this:

'+**********************************************
'*
'$ Function: CalcAge (Calulates age based on date passed)
'*
'* Author:
'*
'* Date:
'*
'* Purpose:
'*
'* Arguments:
'*
'* Revisions:
'*
'-************************************************

Now I can create code to loop thru all of my modules and pull out just the headers (all lines between '+ and '-, inclusive). I now have documentation for all of my functions/subs. For a brief descriptions of all of my routines (index page), I can pull out just the line in the header that begins with '$.

As far as further documentation, I wouldn't bother. Anyone that's going to support your system is going to have to know Access and will know about the properties of forms, etc. The main thing that will help someone who is supporting your system is to produce good error messages. The error messages should include the name of the form/report/module and function/sub that produced the error.

If you spend too much time documenting your system, it will be difficult to keep the doumentation up-to-date. Consequently, you won't be able to count on it. That's why I only worry about keeping the headers up-to-date. And, then when I want the latest version of the documentation, I can just execute my routine that extracts the info. I want.
 
Status
Not open for further replies.

Part and Inventory Search

Sponsor

Back
Top