YouTube OFUG AVFP Presentation last night

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

http://www.youtube.com/watch?v=DaKmRhxS0Z0

Pity it wasn't advertised more....
Editor
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,
Simon
Coordinator
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.
Editor
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,
Simon
Developer
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
        Else     
            SET PROCEDURE TO codeblck ADDITIVE
        EndIf
        oCodeBlock = CREATEOBJECT( "cusCodeBlock") 
        oCodeBlock.SetCodeBlock(cEval) 
        oCodeBlock.lAccumulateMergedText = .T.
        SET TEXTMERGE ON
        oCodeBlock.Execute() 
        lcStr=oCodeBlock.GetMergedText()
x
   ELSE
        *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)
                EXIT
            ENDIF
        ENDDO       
        cEval = [Function ]+lcFunctionName+CHR(13)+CHR(10)+cEval 
        STRTOFILE(cEval,lcFile)
        COMPILE (lcFile)
        SET PROCEDURE TO (lcFile) ADDITIVE

        lcStr= &lcFunctionName()            

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






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