Partager via

Edit and Continue in VFP can save you time

  • Article

Sometimes it takes many steps to reproduce a problem. Perhaps you have to start an application, log in, navigate some forms, menus, etc. until you finally reach a breakpoint in your code. Then you see the problem, want to modify the code and retest. That means executing all those steps again. Or you may be developing a particular component of an application that takes many steps while to navigate to.

The latest version of VB.Net has a feature, called Edit and Continue, which allows you to modify code and execute the modified code, without restarting the application. (I believe this feature was gone for a version or two of VB: can somebody confirm?)

Of course, if you make what’s called a “rude” edit, then VB.Net cannot continue and the app must be rebuilt and restarted. For example, changing a method signature or interface.

I’ve been doing my own “edit and continue” for more than a decade in VFP.

First, if you don’t have to build an APP or EXE file to run your application while developing, then don’t. Many applications can be run by directly DOing the main PRG file or DO FORM the main form. You may have to fiddle with SET PATH TO so that the program can find its constituent parts. An alternative is to Exclude the file from the APP or EXE from the project manager. Once it’s inside an APP or EXE, then it becomes readonly and thus unmodifiable.

Then, take advantage of the fact that once a program is no longer on the VFP call stack, it can be modified. You might need to CLEAR PROGRAM, depending on your application, but the below example doesn’t require it.

Paste the code below into a PRG file and run it. When it reaches the breakpoint, step til you get to “x=2”. Test1 was executed.

Modify the code in Test1 to fix the “bug” by changing the text string it prints to “New version!”.

Now Set Next Statement back to the “x=1” line. The newly modified version of Test1 will be executed!

Design your applications so that you can exploit this feature and you can save lots of time.

Here’s another example of saving time by not building code into the end APP or EXE: in my VFP COM servers, I have no code actually bound into the server, which means I don’t have to rebuild the server to make changes. If it’s a web server, I don’t have to shut down/restart the server or the web application.

See Blogs get 300 hits per hour: Visual FoxPro can count.

CLEAR ALL

ERASE test1.*

SET TEXTMERGE ON TO test1.prg && generate a test program

      \PROCEDURE Test1

      \ ?"now we're in Test1"

      \ RETURN

SET TEXTMERGE to

MODIFY COMMAND test1.prg nowait && open the program in the editor

DoSomething()

PROCEDURE DoSomething

      SET STEP ON && hard coded breakpoint

      x=1

      test1() && execute the program

      x=2 && when we step to here, modify test1.prg, then Set Next Statement back to the x=1 line

      RETURN

Comments

  • Anonymous
    May 01, 2006
    Sweet! Nice tip, Calvin, thanks. :-)
  • Anonymous
    May 02, 2006
    Thanks for showing again why VFP continues to be a great RAD tool, still very viable in today's world.  Now if only others "got it."  ;-)
  • Anonymous
    May 05, 2006
    I always put a bogus command to force the debugger to appear. SET STEP ON is much nicer. Thanks for the tip!
  • Anonymous
    November 02, 2006
    PingBack from http://blog.donnael.com/?p=1300