Yesterday, I came across another reason why VFP 9 totally rocks above older versions.
I've been aware of it for a while but it struck me at once as to how useful this is, especially at customer sites.
SET COVERAGE TO lets you track how long each line of code is taking. It's used by the VFP Coverage Profiler for both seeing how much of your code you are using and how long it takes.
SET COVERAGE TO xxx.LOG turns it on and outputs all code execution to xxx.log
SET COVERAGE TO turns it off.
In VFP 8 and earlier, you had to be running the Development version of VFP to see the results. This has its problems - as usually, the problems never seem to occur on the Developer's machine but on the end-user's machine.
In VFP 9, however, you can issue a SET COVERAGE TO statement and it will start logging the code even in runtime!
This became extremely valuable yesterday when we were debugging a program that was running as a Windows XP service. It would stop running and we couldn't figure out why. Instead of just providing additional logging messages and overbloating the code - I issued a SET COVERAGE TO in one of the programming hooks I had put into the code and voila! instant access as to what was running and when.
You wouldn't want to do this on a regular basis - running with COVERAGE turned on can create a very large file in a matter of seconds - so be sure to turn it off. But what a benefit to have at the right time!
I also used it earlier this week to track down some performance problems that only seemed to be happening at a customer site. Many times, developers think of debugging tools as to be only accessible within the IDE. Thankfully, in VFP 9, your code can be covered just about wherever it needs to be.
I've been aware of it for a while but it struck me at once as to how useful this is, especially at customer sites.
SET COVERAGE TO lets you track how long each line of code is taking. It's used by the VFP Coverage Profiler for both seeing how much of your code you are using and how long it takes.
SET COVERAGE TO xxx.LOG turns it on and outputs all code execution to xxx.log
SET COVERAGE TO turns it off.
In VFP 8 and earlier, you had to be running the Development version of VFP to see the results. This has its problems - as usually, the problems never seem to occur on the Developer's machine but on the end-user's machine.
In VFP 9, however, you can issue a SET COVERAGE TO statement and it will start logging the code even in runtime!
This became extremely valuable yesterday when we were debugging a program that was running as a Windows XP service. It would stop running and we couldn't figure out why. Instead of just providing additional logging messages and overbloating the code - I issued a SET COVERAGE TO in one of the programming hooks I had put into the code and voila! instant access as to what was running and when.
You wouldn't want to do this on a regular basis - running with COVERAGE turned on can create a very large file in a matter of seconds - so be sure to turn it off. But what a benefit to have at the right time!
I also used it earlier this week to track down some performance problems that only seemed to be happening at a customer site. Many times, developers think of debugging tools as to be only accessible within the IDE. Thankfully, in VFP 9, your code can be covered just about wherever it needs to be.
powered by performancing firefox
Comments