>Hi all -
>
>Note: Will try to keep this short; hopefully clear enough to set the stage for the question.
>
>[Short] Background: Working on an old FoxPro app that is launched via a small VFP EXE, which then calls (mostly) stand-alone PRGs scattered in various network folders. In those same folders are tons of old, deprecated PRGs and other source objects that are no longer used but not easily identified as such.
>
>Need: What code (PRGs... not individual lines of code) is actually run in the application, which now really has just one "batch-like" option? This would allow us to know when PRGs need to be migrated to C#, and which can be ignored.
>
>Semi-Gotcha / Constraint: Essentially the EXE cannot be rebuilt. That said, I do have a newly-created VFP Project that would allow me to add code to the launcher in order to obtain the desired log.
>
>Question: What is an effective way of doing this? I could use SET COVERAGE TO someFIle.log before launching the app and running the single still-used option, then query the log for unique modules / PRGs / Forms / etc. But, that log will be ginormous and I could envision an out-of-space issue. The app is also quite long running, and adding SET COVERAGE won't help that.
>
>Any thoughts are greatly appreciated!

How about having a timer at some neat small interval (which still wouldn't slow down the app too much) and then checking the n-1st entry in the array returned by aStack()? I mean, if you can't just add logging to each of the myriad routines, and can't do a coverage log... then why not this?

Another option would be to look into coverage.prg and trim it down to just one line per called routine, i.e. build your own skeleton coverage, log just the cases when the suffix of the called routine is .prg or .fxp... maybe that'd be feasible. (um, not sure this'd be possible, the _coverage variable doesn't change the logger, but the log reader... too bad)