Sep 20, 2013 at 3:53 PM
Edited Sep 20, 2013 at 4:21 PM
That was very good presentation and a great help to new AVFP users.
I do have one observation to make about debugging in V 6.03
My IIS is hosted in-house, so I do not have to debug on remote web sites. However, while developing the local debugger, using VFP only , I faced a problem, that ‘may’ also be the a problem faced by ASP worker process during debugging through VS. Very likely
it is nothing to do with ASP handlers, but it may still be of value to others doing local debugging.
My problem was with the ExecScript() breaking the call stack. If you step into any function, in the code being executed within the ExecScript(), it breaks the debug handle and the trace is switched off.
The solution is to create a real ‘prg’ file on disk, instead of using ExecScript.
I give below the example of the change I made to my copy of activeVFP.MergeScript.
IF [INCLUDE] $ SYS(16,PROGRAM(-1)-1) && prevent recursive error in TextMerge/ExecScript
*-----+ Putting flexible path so that we can debug
If VARTYPE(oProp) = "O" and VARTYPE(oProp.AppStartPath) <> "U"
cpathCodeBlck = oProp.AppStartPath+[Prg\codeblck.prg]
SET PROCEDURE TO (cpathCodeBlck) ADDITIVE
SET PROCEDURE TO codeblck ADDITIVE
oCodeBlock = CREATEOBJECT( "cusCodeBlock")
oCodeBlock.lAccumulateMergedText = .T.
SET TEXTMERGE ON
*lcStr=EXECSCRIPT(cEval) && Microsoft EXECSCRIPT seems to be reliable in VFP9
*----- Aug 2013 .. Create a physical file on disk to enable better handler for debugging.
LOCAL lcFile, lcFunctionName, lcFileFxp
*------+ Play safe for concurrent requests during peak usage times
Do WHILE .T.
lcFunctionName = [p]+SYS(2015)
lcFile = oProp.AppStartPath+[temp\]+lcFunctionName+[.prg]
cEval = [Function ]+lcFunctionName+CHR(13)+CHR(10)+cEval
SET PROCEDURE TO (lcFile) ADDITIVE
Release PROCEDURE (lcFile)
lcFileFxp = FORCEEXT(lcFile,"fxp")
*-----+ Low level error..just keep going.. we'll handle it during directory cleanup