Database development and training for Birmingham and the midlands
Specialists in Microsoft Access and Visual Foxpro database training and development
I am happy to hear from existing clients but I am taking no new calls.
The VFP ASSERT statement
Although Visual FoxPro has a good debugger, there are times when you need a little more information about what's going on - or perhaps you need to be able to see what's going on without the intrusive overhead of the debugger. The classic technique is to use a WAIT WINDOW command to display values at the crucial point in the program.
The screen shot shows a Wait window and it's not the sort of thing that you want a user to see. You can write code to detect whether you're developing or running the program but the Assert mechanism is sometimes easier.
The traditional use of an Assert in more rigorous languages such as C++ or Java is as a guarantee that the program is indeed in the state which the programmer expects it to be in and FoxPro too allows an Assert to be used in this way. This example for instance shows that the programmer expects the Customer table to be open and to be indexed in Name order at this point;
Assert Used("Customer") ;
Message "The customer table must be open."
Assert Order ("Customer") = "Name";
Message "Table must be in Name Order."
If the table is not open or it's not in the right order then there's no point in continuing with the program. The developer needs to find out why these conditions have not been met. Without the Assert, execution would have continued until the point where the program needed to use the Customer table and that might have been several hundred lines of code away, possibly in another method or function altogether. The Assert statement means that the program will stop as soon as we know that something is going wrong, it doesn't allow the error to propagate across the application.
The general form of the command is the keyword followed by a boolean expression. If the expression evaluates as false then FoxPro will display a dialog giving the programmer the options of opening the debugger, cancelling the program or ignoring the failure. The example here makes use of the optional Message clause. Without it we'd just get a generic "Assertion failed on 23 of procedure myProg."
Using Assert to debug
The key word in the previous sentence is 'programmer' because the assert mechanism does not operate at runtime. This also means that you should not be tempted to try to use Asserts as a mechanism for validation during data entry. It will work for you as a programmer but not for the user.
An Assert is meant to be used as an improvement to software quality, to ensure that the developer has got the program environment set up correctly. It does mean though that we can use Assert as a sneaky way of showing us debug information and we can be certain that the user won't see these messages. All we have to do is to write an Assert statement with a boolean expression that will evaluate as false. Something as simple as this:
Assert .F. ;
Message "Postcode is " + customer.postalcode
will show the debug message to the developer but not to the user. If you want to temporarily suppress the messages in the development environment too then you can turn asserts off:
Note that the default is for asserts to be off. You must have a Set Asserts On statement if you want to use asserts at all.