VFP doesn't write any logs on it's own. So there's gotta be a SET COVERAGE line in your code anywhere. In foxypreviewr sourcecode the only two places the word 'cover' appears in the code (alone or as part) are a comment "* Class does not cover General fields, if they were in report expressions" and another comment "&& on possible discovery of an image control mid-way", so Foxy Previewer does no coverage logging whatsoever.
"cover.log" sounds like a name choosen for a coverage log. It doesn't mean anything, though, that this message about the cover.log exceeding the 2GB limit comes from foxypreviewer code. The nature of coverage logging is, it logs every single line of code executing, every single line, no matter what code, your own or others. So an exceeding of the file limitation can happen anywhere. The fault obviously is to always reuse the same coverage log and never start with a new one, this has to break at some time. And it doesn't reset to 0 then, it chokes again and again.
Not mentioning that error and telling reports don't run the preview is a bit like telling your car doesn't accelerate when you give more gas, after the motor choked. Very essential information.
Even if you designed your error handling to ignore repeating errors, the next line executing again writes to the cover.log and again the log will rise above 2GB, revert to somewhere short before 2GB and choke and choke again and again. Coverage is not meant to be run additionally all the time, you should limit your logging to parts of your application known to have a problem. In some cases it might be useful to log all code running, but not for an application rnning indefinately. If you really want to slow down your app and want to do this every time and all the way, the log get's as useful as the whole code of the application is, to finding where an error is. Well, the last line of the log is telling you about the error location, but ON ERROR could do that, too. A few lines before that can help see where you came to the failing line and what pre running code has set the way to the error. That's fine, and that's how coverage logging can help, the intention is actually to do coverage tests, seeing if your testing calls of functions, precedures, methods do cover every case, every line and this if you test calls with text parameter values make the code branch into each case or each if and else branch of any code that does only execute conditionally. If you do too less tests of eg a function having two IF statements, your test may only test the if and else branch of the first IF and the else branch of the second IF, but your end user might cause the if branch of the second IF to run and there might be an error your tests haven't covered. That's where the name coverage log comes from, and the default mode of the coverage profiler will show you which branches of code have executed and therefore been tested and which not.
2GB log of code having executed are just a wast of disc space and user time, as coverage logging really slows down the application. Did I say it's logging each single line of code executing? In a loop it's not logging each line of the loop once, it's logging each line of the loop as many times as the loop repeats the execution of it's loop body. You don't need that, you don't want that.
What you should do at least, is to restart with a new log file at every program start. 2GB are very little space for such extensive logging of every single line of code executing and it's only needed for debugging purposes, not as a standard way of logging everything that runs to be able to spot where errors happen. This is also missing essential info: Variable values and states. So it's a huge log not even giving you all the answers you'd need in all cases to debug errors.
To clear things at startup with CLEAR and CLOSE command is not needed for an EXE, but can't hurt and will help you to reset whatever you did in development, if you test starting the main.prg within the IDE, therefore I could have been the one recommending these lines, but they are not needed for an EXE, and they don't stop coverage logging, as far as I know, have to test that.
The thing "officially" stopping coverage log is SET COVERAGE TO (without a file name, just the pure SET COVERAGE TO, like SET ORDER TO set's no order, this sets no coverage log file and therefore ends logging). But coverage logging also doesn't start without a SET COVERAGE line.
Bye, Olaf.
