Home | Web Design | Programming | Fairlight CMI | Soap Box | Downloads | Links | Biography | About... | Site Map |
Providing Default Parameter Values |
CA-Clipper | Opportunities | Tips and Tricks | Networking | Internal Errors | Source Code | CA-VO |
BACK TO CA-CLIPPER TIPS & TRICKS |
A primary rule of programming with CA-Clipper (and with other
languages) is to make functions "smart". In CA-Clipper, this often
means that useful default values should be supplied for function
parameters. A classic example of a smart function is the dbedit() function.
It was designed to accept many parameters (as many as twelve), all of which
are actually optional. Here is the definition of the function, from the
Norton Guides on-line manual that comes with CA-Clipper:
dbedit()
as simply as this: use CUSTOMER new This provides a browse window that fills the screen and displays all of the fields of the table. The nTop, nLeft, nBottom, and nRight parameters would automatically default to 0, 0, 24, and 79 (assuming a standard VGA screen size). If you want to display the browse in a smaller window, you can pass screen coordinates as the first four parameters: dbedit(10, 10, 20, 70) This browse still displays all of the fields, so if you want to limit the display to certain fields in the table, you can pass an array of field names: dbedit(10, 10, 20, 70, {'NAME','ADDRESS'} ) If you want to skip parameters (thus falling back to the default values), you still need to specify the correct number of commas: dbedit( , , , , {'NAME','ADDRESS'} ) Without going any further into the dbedit() function, you can
see that optional parameters and smart default values are very useful in
removing some of the complexity from your source code. |
One of your goals when writing functions is to make it easier to use
them. So to implement smart default values for parameters you typically
check the parameters to see if they have been assigned a value. This is
done by comparing them to the special value NIL . The examples
that follow illustrate the source code as it might have been written inside
the dbedit() function.
dbedit() function also checks the data type of the
parameters, since it is possible to pass a string where a number is
expected. The valtype() function is used to see if the data
type of the parameter matches what is expected.
nTop parameter is not a
number, then set it to 0". Similarly for the rest of the parameters. In order to make this source code easier to read, it is a good idea to create a new command in the CA-Clipper language. This is done by harnessing the power of the CA-Clipper pre-processor (which translates your source code according to specified rules before it is compiled). Here is the definition of this new comand: #xcommand DEFAULT NUMERIC <v> TO <x> => ; And here it is (as it might have been used) in the dbedit()
function:
I have created several of these commands, covering each of the data types in CA-Clipper. The commands are contained in a file called DEFAULT.CH , which is included at the top of most of my source
code files.
end statement is used above, rather than the
preferred endif statement. The end spelling can
be used in place of endif , enddo , and
endcase , but the shorter form is not as clear as the full
spelling. In other words, when multiple end statements are
encountered (as would be the case with nested loops), it is hard to tell
them apart. However, in this context the end spelling is necessary in
order to overcome a strange bug in the CA-Clipper pre-processor. The bug
causes source code after an endif to be ignored when
processing #xcommand translations. Here is a simple example showing the use of the new commands:
|
Home | Web Design | Programming | Fairlight CMI | Soap Box | Downloads | Links | Biography | About... | Site Map |
Send comments about this site to Greg at
gregh@ghservices.com All pages copyright © 1996-1999 GH Services Created 1997/07/15 Last updated 1999/09/30 All trademarks contained herein are the property of their respective owners |