Automatic Documentation

[Colin Burton]

Hi All

Back in the day, many moons ago, I first started with MfoxPlus ! - yes before Foxpro - all under DOS too

I recall there was a free utility that came with The Fox - if I recall correctly it was called FoxDoc

This was a wonderful little application, you gave it the name of your "main" prg file and away it went and did some work.

you got lists of variable, programs and screens etc, too much for me to remember, and for each prg file, which other prg's called it, and which prg's it called - which in itself was very useful

you could optionally have a flow of each prg file - I remember printing those out on a Dot Matrix Printer and using pages and pages of paper.

Anyway - the question ? -

does anyone know of similar tools nowadays - I seem to rely on GoFish - and the built in code references - but what i really miss is the x - referencing of what code calls what other code

TIA

Colin

 

[Mike Lewis]

Colin, it's sounds like you need the Documenting Wizard. In the FoxPro IDE, go to Tools / Wizards / Documenting, and follow the prompts from there. Note especially the various output options in Step 5.

I have to say that I don't think the Documenting Wizard is as good as the old FoxDoc, but it should meet your needs.

Mike

__________________________________
Mike Lewis (Edinburgh, Scotland)

Visual FoxPro articles, tips and downloads

 

[Chris Miller]

I second Mike,

I just think you won't get these references from the documenting wizard.
Thinking about what it means, it would need to parse code and understand in which object variables or properties which classes get instanciated and which methods are called, but also which events are raised.

It's not that straight forward to find cross references of calls in OOP constructs than in mere procedural programming. But on the other hand cross references of classes with other classes actually point out violating the encapsulation principle, i.e. an object should mainly care for itself and the inteface with anything else should be very slim and targetted, otherwise you have dependncies across libraries, and class families that are not so easy to maintain.

Code references is fineto find soething within the whole project, but then, if you want to find out what happens, the first thing you should look into is debugging in single step mode. Do yourself a favor and make the debugger your friend, usage is as simple as setting a breakpoint at some starting point in the code you want to know more about how it works and what it does and trigger.

You can also go in fast forward mode and use coverage logging to see what code executes, it might not be as easy to follow if there are lot of jumps to other classes and forms and objects in general, where the debugger simply swaps to whatever other objects code, but you could also summarize which files are involved from the coverage log.

If I'm new in a project that's not as much documented as you would like to have documentation you always at least know where an EXE starts in the main file of a project and I get the best overviw with both debugging in single step mode and also coverage logging.

Chriss

 

[Mike Lewis]

And be warned that the Documenting Wizard might take a very long time to run. After I posted the above, I thought I would run it on one of my larger projects, to remind myself what the output looks like. Twenty minutes later it was still running. I don't remember that ever being a problem with FoxDoc. (Then again, our projects were very much smaller in those days.)

Mike

__________________________________
Mike Lewis (Edinburgh, Scotland)

Visual FoxPro articles, tips and downloads

 

[mJindrova]

Exist a few utils for documentation for VFP 9.

older thread:

https://www.tek-tips.com/viewthread.cfm?qid=1798366

mJindrova

 

[Chris Miller]

referencing of what code calls what other code

Just for showcasing the difficulty of that. Imagine some class is instantiated into an object on a form and then called from a child object by

THIS.PARENT.methodcall()

from the code alone it doesn't become apparent what THIS.Parent is during runtime.

So when you're mainly after such dependencies, code references can find calls named "methodcall", which depending on the method names might be very limited to only that one class, but some method names might be used in several classes, of course, all classes of a class hierarchy inheriting a method will also have this in common. And as another example finding what code removes an object by setting it to NULL isn't findable by searching for NULL alone. That aspect of documenting takes a lot more of code understanding to get to the bottom of everything.

Chriss

 

[Colin Burton]

Hay,

I never said it would be easy ! !

I was partly reminiscing, and partly looking for other suggestions as to how to approach , thanks for the replies, really rather just backs up my original post, code references, and gofish - if I get some time I will take a look at the documenting wizard.

 

[Chris Miller]

Code references and gofish are merely search tools, they don't teach you the structuring of a project, the references and the dependencies you're after. And no documenting wizard does more than just listing all class methods and their parameters and functions and procedures and their parameters.

I still say the best thing to find out something specific is single stepping through code with debugging or statistical analysis of a coverage log by means of several thingss, but mainly by files involved.

Chriss