Visual FreePro will run on a new virtual machine, called the VVM (Visual FreePro Virtual Machine). As such, VXB++ introduces the concept of PURSUE execution using the new PURSUE keyword.

A PURSUE can be thought of like BEGIN TRANSACTION, except that a PURSUE does not work just with data, but rather with everything that can be done in source code.

PURSUE begins a type of "not yet committed" execution buffer on all variables, tables, everything, whereby all normal processing takes place, but the results stored in that buffer must later be accepted or rejected using the new PACCEPT and PREJECT keywords. If the program terminates before issuing PACCEPT, they are, by default, rejected.

PURSUE execution levels can also be nested, meaning you can be in one PURSUE and initiate another, and another, and so on. Each one in turn must be explicitly accepted or rejected in and of itself, and any lower-level PURSUEs which were accepted will ultimately have their results rejected if any higher level PURSUE is ultimately rejected.

PURSUEs can be initiated either explicitly in source code, or as an adhoc command from inside the debugger. The debugger can also accept or reject any PURSUE (whether it was initiated in source code or not).

The purpose of the PURSUE is to aid the developer both in writing source code, and providing powerful features for the end-user to experience.

For source code, a developer could make a change (which due to the edit-and-continue nature of Visual FreePro IDE and debugger, that change can happen right in the middle of debugging (where it is also compiled in real-time automatically)), enter a PURSUE to test it (with a breakpoint after the part being tested), and then either accept or reject it. If accepted, normal execution continues on from there using all of the values that were set in the PURSUE. If rejected, everything is undone and the developer can re-code the algorithm and try again by entering another PURSUE and trying again.

For end-users, the ability to give the user a sample "year end close" exists without writing any code changes at all, except an IF block which tests if the user is running a "trial year end," which would signal the start of the PURSUE whereby all normal processing for year end could take place, allowing for reports to be generated afterwards, an inspection of beginning balances, etc., to later be rejected as the user goes back to normal processing. This feature would be given for every task that exists in a system simply by entering a PURSUE, doing the thing, and then issuing PREJECT in source code.

Mechanically, Visual FreePro and the VVM virtual machine engine both use a particular memory use design which allows for these buffers to be maintained in variables and objects with almost zero overhead. The only place where this will not work is if a developer is using SQL pass-through, as all transactions transmitted to a non-Visual FreePro server will not be part of the PURSUE execution. If the commands are being sent to a remote Visual FreePro server, it will also be queued even when using SPT.

Visually, PURSUE execution shows up in the debugger as a blue highlighted source code line during single-step operations, whereas normally the line is green. In addition, there are debugger windows which allow the examination and comparison of memory variables, tables, fields, objects, etc., between PURSUEs as well as the prior non-PURSUE data.

VXB++ also provides the (|HARDEXECUTE|) cask, which can be prefixed before any source code line. This cask instructs the VVM to physically store the result of that particular line of source code into all PURSUE buffers, as well as the original data before the first PURSUE was entered. This feature was added primarily to allow permanent reporting of what the user did during a PURSUE, so that such activity can be logged. However, it can be used for any purpose.

-----
It is the features of the new virtual machine which make this ability possible, and it was for this one reason that I've spent all this time designing Visual FreePro to operate in and around the virtual machine -- ever since I made the decision to do so back in August, 2012.

It's been a lot of work. And a lot more work is is needed. But the final fruits are proving highly anticipated, and should be exceedingly delicious. :-)