Documenting a VFP6/7/9 Application 2

[harryjr]

Does anyone know of an existing Application that will document a VFP6/7/9 Application providing a "Program Calling" chart (ie, starting at MAIN program list all the programs called and where each is called from)?

Thanks,

Harry

 

[mm0000]

You could try PDM - the freeware tool for project documentation. You can download it from

http://gorila.netlab.cz/pdm.html

 

[Mike Lewis]

Harry,

Would the VFP Documenting Wizard (on the Tools menu) do what you want? It's a very long time since I used it, but I recall it generates something similar to the call stack you are looking for.

Mike

__________________________________
Mike Lewis (Edinburgh, Scotland)

Visual FoxPro tips, advice, training, consultancy
Custom software for your business

 

[harryjr]

mm0000,

Thanks for the response but that application does not produce a TREE of the procedures.

Mike Lewis,

I had already tried that WIZARD but is doesn't produce what I am looking for. Thank you for your response.

Harry

 

[GriffMG]

What exactly are you after, the documenting wizard in vfp9 does produce a 'tree diagram' - although I can't see the point of it myself, it doesn't SEEM to do anything usefull, and the files it uses to create it don't look like they could be processed to help either!


Regards

Griff
Keep [Smile]ing

There are 10 kinds of people in the world, those who understand binary and those who don't.

 

[harryjr]

Griff,

What I was hoping to produce is a TREE DIAGRAM that shows ONLY procedures (functions) that are called from a higher level procedure. I have a very large application that I want to document for future reference by adding text to the heading of each individual procedure identifying the procedure that CALLS IT and the procedures IT CALLS.

Harry

 

[Mike Lewis]

Harry,

I have a very large application that I want to document for future reference by adding text to the heading of each individual procedure identifying the procedure that CALLS IT and the procedures IT CALLS.

I can see why you might want to do that, but are you sure it's a good idea?

If you add text to your code to indicate all of a routine's callers, you would have to constantly update that text as and when things change. One of the points about using a subroutine is that you can call it from anywhwere at any time, without having to actually look at the subroutine's code. By requiring you to change the text every time you call the routine (from anywhwere in the app), you will make it harder to modify your code.

Mike

__________________________________
Mike Lewis (Edinburgh, Scotland)

Visual FoxPro tips, advice, training, consultancy
Custom software for your business

 

[GriffMG]

It sounds like SNAP - the tool we used to use to document Clipper stuff. But that was only good for code only developments.

I haven't seen the like for VFP.

Could 'code references' be used - does it create tables?

Regards

Griff
Keep [Smile]ing

There are 10 kinds of people in the world, those who understand binary and those who don't.

 

[Dan Freeman]

Griff,

SNAP became FoxDoc with Foxpro 1.0, and is now known as the VFP Documenting Wizard.

 

[GriffMG]

Hi Dan,

Yes, that makes sense - extending Snap to make foxdoc/VFP Documenting Tool. The only snag is the 'tree diagram' isn't much help!

Regards

Griff
Keep [Smile]ing

There are 10 kinds of people in the world, those who understand binary and those who don't.

 

[harryjr]

Mike,

My reason for the DOCUMENTATION is not for me. I'm a very old programmer who will most likely pass this Application to another very shortly. I just wanted to make it easier for him to initially be able to follow the sequence of the process until he becomes familiar with it.

Thanks to all for their responses...

Guess I'll have to do it manually ...

Harry

 

[Mike Lewis]

Harry,

Makes sense. But I would think a straight list of every function and procedure with a list of all its callers would be better than inserting that information into the code.

I hope you manage to do it, one way or the other.

Mike

__________________________________
Mike Lewis (Edinburgh, Scotland)

Visual FoxPro tips, advice, training, consultancy
Custom software for your business

 

[TamarGranor]

I'm with Mike. DON'T put that information in the headers.

The refactoring people say "Comments lie." On a project I'm working on now, I'm finding out just how true that is. We wrote good comments, but over time, things change. We try to document every change, but we definitely have comments in the code that just aren't true anymore.

Tamar

 

[harryjr]

Mike and Tamar,

I'll take your advice and create a stand-a-lone DOC.

Harry

 

[agbtech]

Don't know of any, so I wrote a series or prgs to do it for me. There were a lot of manual steps initially, including using the wizard after recompiling the projects beginning only with the main program (to eliminate "junk"). It took a month or two to document 20 applications, their source, calls, and what was called from where on what line of code.
I dumped it all in several dbfs and also produced some reports in pdf style. Finally I was able to then write a small program that "searched" through the dbfs for specific calls or called programs, forms, functions etc. and produce a report. Saved lots of time in the long run.

 

[billch]

Hi AgbTech,

I'm in the midst of doing something similar--though I haven't yet solved the "calling/system tree" report. Any chance you can post your code?

Everyone else: I have come up with a system for dynamically updating documentation based upon the results of the VFP Documenting Wizard. (Think Documenting Wizard on steriods).

Does this have the potential for a VFPx project? I'm willing to roll up my sleeves...

Bill Chambers
Chambers & Associates

http://www.ChambersData.com