print vba code flow chart for procedures

[the_net_2.0]

has anyone worked with large programs here? this is a cont. of this thread, sort of: http://www.access-programmers.co.uk/forums/showthread.php?t=211009

but at any rate, my vb6 project has 500K+ lines of code in it and I'm trying to figure out how to print the CALL statements out from the project. I've already got the extensibility code written, but I'm not sure what method I should use.

for instance, should I use I/O and print out a diagram of single procedures that I find, in order, separated by -----> arrows or something, so I can take the .txt diagram to the print shop and have them print it out for me??

Or should I maybe print out the flow to an .xls file??

does anyone have any suggestions for me on the best way to do this??

basically what I want in the end is a readable flow chart of this program's code, so I can see what code runs from where, what code is called from where, etc...

Again, I've already got the code written so it can be modified to produce whatever output I decide on.

any thoughts?? thanks!

 

[DJkarl]

Is this flow chart for you or for others? The reason I ask is that from what I see basically you are going to get a giant list of function names with no code or logic around them, to you the programmer this may be of some use, but to anyone else what is it really going to tell them? The approximate order functions run in, but not what the functions do or if they are actually called. Seems like an aweful lot of effort for little return IMO.

 

[the_net_2.0]

it IS a lot of effort for not much return. hence, it is only for me.

I know the program well enough now that I partially know the sequencing of the coding, but having a large sheet with this stuff printed out on it would help reduce the time it takes to fix coding issues immensly. As you know, I'm sure.

as I said, it is for me only. at this point though I'm not even sure HOW to write the code to do it. here is my initial inclination:

ARRAY1 ---> stores modules and their indexes, 2 dimensions
ARRAY2 ---> stores procedure names for each module, 2 dimensions

*loop modules, check for CALL statements in each procedure
*loop module where CALL procedure is and read that proc for any CALL statement
*etc, etc...

that's a start of course, but that's a heck of a lot of coding, and complex to follow as well!

 

[ChrisO]

Adam, I suspect you are wasting your time, and others.

Please try to automatically document the Procedure Calls in the Access 2003 attachment, there are approximately 2400.

Chris.

 

[the_net_2.0]

no thanks, Chris. why would you ask such a thing anyway?

Talk about wasting time... ?

 

[ChrisO]

Because if you can’t answer that question you won’t be able to do it.

 

[SteveH2508]

If you use MZ-Tools (a freebie which adds much functionality to the VB IDE) it has a feature which allows you to see the calling procedures for any procedure. This is very helpful.

 

[ChrisO]

In the attachment in post #4 there is a Function called:-

Public Function HandleClick(ByVal strControlName As String)

It has 600 callers and MZ-Tools will not find any of them.

Chris.

 

[DJkarl]

it IS a lot of effort for not much return. hence, it is only for me.

I know the program well enough now that I partially know the sequencing of the coding, but having a large sheet with this stuff printed out on it would help reduce the time it takes to fix coding issues immensly. As you know, I'm sure.

as I said, it is for me only. at this point though I'm not even sure HOW to write the code to do it. here is my initial inclination:

ARRAY1 ---> stores modules and their indexes, 2 dimensions
ARRAY2 ---> stores procedure names for each module, 2 dimensions

*loop modules, check for CALL statements in each procedure
*loop module where CALL procedure is and read that proc for any CALL statement
*etc, etc...

that's a start of course, but that's a heck of a lot of coding, and complex to follow as well!

Does your project have line numbers in the code? That is probably the best way to debug and trouble shoot, if you don't I would suggest spending time writing a tool to go into your source and add line numbers to your code, then in your Error Handler Err.Number will give you the exact line number that the error occured on. It would be a lot less effort and yeild a similar goal of being able to pinpoint where the error has happened.

 

[the_net_2.0]

Does your project have line numbers in the code? That is probably the best way to debug and trouble shoot, if you don't I would suggest spending time writing a tool to go into your source and add line numbers to your code, then in your Error Handler Err.Number will give you the exact line number that the error occured on. It would be a lot less effort and yeild a similar goal of being able to pinpoint where the error has happened.

the purpose of this is NOT to speed up debugging processes though. this program is huge and I'm completely new to the industries lingo. That's the reason I want this. It has nothing to do with error handlers, etc...

a flow chart of the code, what it does and where it goes from start to finish at any given entry point will be extremely useful to me, and will also help me sound professional when talking about this stuff!

That's really the motivation behind this. But I actually have another idea of how to go about doing this that doesn't take a million multidimensional arrays. Shouldn't be too bad to write. I won't get to it this weekend, but when I do I will surely post it in this thread, if I can find it again at that pt!

 

[DJkarl]

Well best of luck to you in your adventure. I don't quite get the point of the excercise, but perhaps when/if you post an example of what does the light will go on and I will.