YouTube OFUG AVFP Presentation last night

Topics: Developer Forum, Project Management Forum, User Forum
Sep 18, 2013 at 2:55 PM
Covers a lot of what's going on with ActiveVFP:

Pity it wasn't advertised more....
Sep 18, 2013 at 4:33 PM
Hi Claude,

Great presentation last night!

Yes It is a shame that it wasn't advertised more but I'm sure that many will watch it on youtube later though.

On that note, are you intending to share this link on LinkedIn e.g. FoxPro and/or Visual FoxPro Developer groups?

If not, are you happy for me to do so?

p.s. I did tweet about the presentation beforehand and it was "retweeted" by 2 others and I've just noticed that it's already had 28 views.

Best regards,
Sep 18, 2013 at 4:49 PM
Thanks Simon. Yes, you can share this link as much as you want. The UT and Foxite would be other good places to share it.
Sep 18, 2013 at 5:24 PM
OK, will do.

BTW, already created a tweet for video and it's already been retweeted (@TamarGranor)

All the best,
Sep 20, 2013 at 4:53 PM
Edited Sep 20, 2013 at 5:21 PM
Hi Claude,

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" 
            Local cpathCodeBlck
            cpathCodeBlck = oProp.AppStartPath+[Prg\codeblck.prg]
            SET PROCEDURE TO (cpathCodeBlck) ADDITIVE
            SET PROCEDURE TO codeblck ADDITIVE
        oCodeBlock = CREATEOBJECT( "cusCodeBlock") 
        oCodeBlock.lAccumulateMergedText = .T.
        *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]
            IF !FILE(lcFile)
        cEval = [Function ]+lcFunctionName+CHR(13)+CHR(10)+cEval 
        COMPILE (lcFile)

        lcStr= &lcFunctionName()            

        Release PROCEDURE (lcFile)
        lcFileFxp = FORCEEXT(lcFile,"fxp")
            DELETE FILE(lcFile)
            DELETE FILE(lcFileFxp)
            *-----+ Low level error..just keep going.. we'll handle it during directory cleanup

Sep 21, 2013 at 12:18 AM
Thanks for this contribution. I'll check it out!!