Debugging in VFP prior to AVFP Posting

Topics: Developer Forum
Jan 26, 2013 at 9:49 PM
Edited Jan 27, 2013 at 1:32 PM

Maybe this is an obvious observation, but it wasn't to me a couple days ago.

I was loading PRGs onto AVFP on the web and spending time debugging directly in AVFP, but I found that simply debugging in VFP was faster and more efficient. 

In the code below, I basically create some custom objects that I can uncomment when I need to test.  In that way, I don't need to concern myself with the odd -- to VFP -- way of oProp calls in AVFP.   I simply created a dummy custom Object and properties for testing.

Seems like the PRG files take some time to clear in the on-line buffer.  My experience is you can't copy PRGs right away to the web server.   So if I have a pagnav.prg to update, I simply rename it pagnav1.prg and upload that without getting a "file is in process" message.  ( NOTE: See reply below which solves this issue. )

*
* pagenav.prg - Page Navigator code
*
* Test Settings to Use when you are debugging directly in VFP -- Simply comment and uncomment them as needed. 
* Also you will need to uncomment and comment the LPARAMETERS line accordingly.


*       Comment these out in production mode.
*!*    lnRowsPerPage = 10     && Rows per page
*!*    lnPagesToShow = 5      && Pages to display on the Pagenav widget
*!*    lnCurrentPage = 2      && Current page number
*!*    lcDirection   = "Next" && Vale of button -- Next, Prev, First, Last
*!*    lnRecordCount = 100    && Total records in the cursor
*!*    oProp = NewOBJECT("Custom")
*!*    oProp.AddProperty("Scriptpath")
*!*    oProp.AddProperty("Action")
*!*    oProp.AddProperty("SessID")
*!*    oProp.ScriptPath ="Scriptpath"
*!*    oProp.Action     = "Action"
*!*    oProp.SessID     = "SessID"

LPARAMETERS lnRowsPerPage,lnPagesToShow,lnCurrentPage,lcDirection,lnRecordCount

Coordinator
Jan 27, 2013 at 12:16 PM
Edited Jan 27, 2013 at 12:49 PM

You said:

"Seems like the PRG files take some time to clear in the on-line buffer.  My experience is you can't copy PRGs right away to the web server.   So if I have a pagnav.prg to update, I simply rename it pagnav1.prg and upload that without getting a "file is in process" message."

As noted in the Documentation and recently on Foxite:

"FOR PRGs (procedure libraries or classes), you simply need to close them if you plan on modifying them. Like so(from main.prg or whatever script file at the end):
*!* oAA=null && Clear class and program from memory
*!* CLEAR CLASS ('schedbizobj') && Clear class and program from memory
*!* CLEAR PROGRAM ('prg\utiltest2.prg') && Clear class and program from memory
*RELEASE PROCEDURE 'c:\avfp5.61Demo\prg\utiltest' && Clear class and program from memory

FOR DATA: issue a CLOSE DATA (uncomment in main.prg)
* CLOSE DATA && optionally close tables after each hit
* now we'll return the HTML output to the browser
RETURN lcHTMLout"

There's also the new CompileIfNew command in the new version that you can insert in there and it will compile it if the source is newer than the compiled object for total and immediate automation.

SET PROC to 'c:\avfp6\prg\compileifnew' additive

RETURN compileifnew('avfputilities') && returns .T. if compiled and .F. if no need to compile

Jan 27, 2013 at 1:30 PM
Edited Jan 27, 2013 at 1:30 PM

This is great.   So as long as use compileifnew(), we actually don't need to upload .FXP files.  That's a nice enhancement.   Thanks much.

Coordinator
Jan 27, 2013 at 2:32 PM
Edited Jan 27, 2013 at 2:38 PM

Here is the source for people with older versions, if they want to use it:

 

*CompileIfNew.prg

LPARAMETERS lcPrgName

 *must be compiled object and compile is source date newer        

  IF !FILE(oProp.AppStartPath+"prg\"+lcPrgName+".fxp") OR ;

   FDATE(oProp.AppStartPath+"prg\"+lcPrgName+".prg",1) > FDATE(oProp.AppStartPath+"prg\"+lcPrgName+".fxp",1)

            COMPILE oProp.AppStartPath+"prg\"+lcPrgName+".prg"

   RETURN .T.

  ELSE

   RETURN .F.

  ENDIF

Jan 27, 2013 at 3:38 PM

Great tips, thanks. My arch nemesis is the dreaded syntax error easter egg hunt. 

I've found opening the .AVFP / .HTML file in VFP and stripping out anything between the <% %> and then SAVE AS: TMP

reveals the bugaboo.

Jan 27, 2013 at 3:54 PM

I should add, I use Notepad++ exclusively.

Right out of the box NP++ highlights HTML tags AND <%= %> - can't recommend it enough.

Jan 27, 2013 at 5:51 PM
Edited Jan 27, 2013 at 5:52 PM

Hey Markmalxx,

I'm also a big fan of Notepad++.  And yes, the syntax coloring is great.   Too bad they don't have CSS error detection on the same page as HTML.  But we can't have everything.

Quick question for you: Once you've finished editing an AVFP file in Notepad++, do you have an automated or semi-automated way to upload that file to the AVFP website?

Cheers. . .

Jan 27, 2013 at 6:44 PM

Batch file:

~~~  AVFP.BAT ~~~~~~~~~~

E:\
CD \AVFP
FTP -v -n -i -s:AVFP.TXT



~~~  AVFP.TXT  ~~~~~~~~~~
OPEN ftp.mysite.com
USER username password
cd html
binary
lcd AVFP
mput *.AVFP
close
quit

Jan 27, 2013 at 8:08 PM

Nifty little Batch file, Mark.  Thanks.

Jan 28, 2013 at 12:18 AM

I'd be lost without batch files. I was trying to make a specific point about the -S: .TXT file in the last post.

I first copy only "today''s" stuff into a sub-folder and then ftp upload:

 

~~~  AVFP.BAT ~~~~~~~~~~

E:\
SET DATE=%date:~4,2%-%date:~7,2%-%date:~10%
DEL \AVFP\NewToday\*.*
MD \AVFP\NewToday
XCOPY \AVFP\*.*  /D:%date%  \AVFP\NewToday
FTP -v -n -i -s:AVFP.TXT

~~~  AVFP.TXT  ~~~~~~~~~~
OPEN ftp.mysite.com
USER username password
cd html
binary
lcd E:

lcd AVFP
lcd NewToday

mput *.*
close
quit