In a recent code compile of a client's application, I noticed some immediate compilation warnings pop up. The application ran fine but the errors were related to functions that exist in the ever popular FOXTOOLS library.
As some background, FoxTools is a FoxPro API library that provide a wide variety of functions (mostly found in the Windows DLL) that, at one point, were not available in FoxPro (going back as far as FoxPro 2.6). Since then, every edition of Visual FoxPro has introduced new functions replacing the need for using Foxtools (to give you an idea about some of the functions that exist in the FOXTOOLS.FLL, check out this post but you can also see it by opening FOXTOOLS.CHM in your VFP Home folder).
Now, when some of the functions were added into VFP, they were added using the same syntax as in the library, thereby requiring no code changes (yeah!). However, others were renamed to be more VFP like. The one that immediately comes to mind is GETFILEVERSION() and AGETFILEVERSION (the native VFP function).
Most VFP array functions all accept the array as the first parameter (examples: ASCAN(arrayname,search), APRINTERS(arryname), ADIR(arrayname,skeleton). The FoxTools.fll GETFILEVERSION() function passed the array as the second parameter:
The VFP native function is much more standardized:
So it's a one character change - (not necessarily trivial if you have a lot of updates to make) - pretty straightforward.
But the code I came across used two of the other FoxTools functions that many developers like to use that have been upgraded in recent versions of FoxPro: WORDS() and WORDNUM().
From FoxTools, WORDS( ) returns the number of words in a particular string and includes a second parameter for the delimiters available. WORDNUM() returns the actual word requested. Example (and yes, note there is no space after the first comma).
returns 5. Wait, you say, there are actually 6 words in there. Well, by default, WORDS() only treats spaces and tabs as delimiters so it misses that comma. So let's do:
With the second parameter, all of the characters that would delimiter a word are passed. This can go one step further with WORDNUM.
returns simply "Bond"
The VFP functions are similar and perhaps make the code a little more readable (a subjective distinction to be sure). Otherwise, the functions are identical:
A quick note - the delimiter parameter is simply a list of characters are used. I put the CHR(9) in there so you can see the "tab" instead of the other chars. A great opportunity to use the #DEFINE statement.
Changing the WORDS and WORDNUM functions in the code to the VFP internal functions removed the annoying compile time errors (a nit-picky issue to be sure) but also can make the code a little easier to read for VFP developers who may not be familiar with the Foxtools functions.
Why Get Rid of FoxTools?
So is this really necessary? After all, if Foxtools is available - why not use it?
1. Fewer files to distribute and variables to deal with. If you can do it from within VFP, why not? In addition, if you forget to say SET LIBRARY TO - you get errors (ugh!).
2. Performance. OK - this may be squabbling over tenths of seconds - but in my quick test (using War and Peace as the great example), the FoxTools functions were slower than the VFP counterparts. Not by much (less than a tenth of a second) but still there.
(Aside: for a great article on neat tricks with VFP and War and Peace, I point you to Steven Black's much reprinted article on text)
These functions were added to FoxPro with version 7 - so unless you're still working in VFP 6, there is no good reason - or is there?
Ok, there may be one argument for keeping Foxtools around in the above scenario - variable length.
WORDS and WORDNUM are not as big as GETWORDCOUNT() and GETWORDNUM(). Is that a real reason? I don't think so but you might.
Do you have any others?
As some background, FoxTools is a FoxPro API library that provide a wide variety of functions (mostly found in the Windows DLL) that, at one point, were not available in FoxPro (going back as far as FoxPro 2.6). Since then, every edition of Visual FoxPro has introduced new functions replacing the need for using Foxtools (to give you an idea about some of the functions that exist in the FOXTOOLS.FLL, check out this post but you can also see it by opening FOXTOOLS.CHM in your VFP Home folder).
Now, when some of the functions were added into VFP, they were added using the same syntax as in the library, thereby requiring no code changes (yeah!). However, others were renamed to be more VFP like. The one that immediately comes to mind is GETFILEVERSION() and AGETFILEVERSION (the native VFP function).
Most VFP array functions all accept the array as the first parameter (examples: ASCAN(arrayname,search), APRINTERS(arryname), ADIR(arrayname,skeleton). The FoxTools.fll GETFILEVERSION() function passed the array as the second parameter:
DIMENSION la(1)
IF GETFILEVERSION("MyAPP.EXE",@la)>0
ENDIF
IF GETFILEVERSION("MyAPP.EXE",@la)>0
ENDIF
The VFP native function is much more standardized:
IF AGETFILEVERSION(la,"MYAPP.EXE")>0
ENDIF
ENDIF
So it's a one character change - (not necessarily trivial if you have a lot of updates to make) - pretty straightforward.
But the code I came across used two of the other FoxTools functions that many developers like to use that have been upgraded in recent versions of FoxPro: WORDS() and WORDNUM().
From FoxTools, WORDS( ) returns the number of words in a particular string and includes a second parameter for the delimiters available. WORDNUM() returns the actual word requested. Example (and yes, note there is no space after the first comma).
lcText = "The name is Bond,James Bond."
? WORDS(lcText)
? WORDS(lcText)
returns 5. Wait, you say, there are actually 6 words in there. Well, by default, WORDS() only treats spaces and tabs as delimiters so it misses that comma. So let's do:
? WORDS(lcText,CHR(9)+" ,")
With the second parameter, all of the characters that would delimiter a word are passed. This can go one step further with WORDNUM.
? WORDNUM(lcText,4)
returns "Bond,James" whereas:? WORDNUM(lcText,4,CHR(9)+" ,")
returns simply "Bond"
The VFP functions are similar and perhaps make the code a little more readable (a subjective distinction to be sure). Otherwise, the functions are identical:
? GETWORDCOUNT(lcText) && Returns 4
? GETWORDCOUNT(lcText,CHR(9)+" ,") && Returns 5
? GETWORDNUM(lcText,4,CHR(9)+" ,") && Returns "Bond"
? GETWORDCOUNT(lcText,CHR(9)+" ,") && Returns 5
? GETWORDNUM(lcText,4,CHR(9)+" ,") && Returns "Bond"
A quick note - the delimiter parameter is simply a list of characters are used. I put the CHR(9) in there so you can see the "tab" instead of the other chars. A great opportunity to use the #DEFINE statement.
#DEFINE _worddelims CHR(9)+" ,"
Changing the WORDS and WORDNUM functions in the code to the VFP internal functions removed the annoying compile time errors (a nit-picky issue to be sure) but also can make the code a little easier to read for VFP developers who may not be familiar with the Foxtools functions.
Why Get Rid of FoxTools?
So is this really necessary? After all, if Foxtools is available - why not use it?
1. Fewer files to distribute and variables to deal with. If you can do it from within VFP, why not? In addition, if you forget to say SET LIBRARY TO - you get errors (ugh!).
2. Performance. OK - this may be squabbling over tenths of seconds - but in my quick test (using War and Peace as the great example), the FoxTools functions were slower than the VFP counterparts. Not by much (less than a tenth of a second) but still there.
(Aside: for a great article on neat tricks with VFP and War and Peace, I point you to Steven Black's much reprinted article on text)
These functions were added to FoxPro with version 7 - so unless you're still working in VFP 6, there is no good reason - or is there?
Ok, there may be one argument for keeping Foxtools around in the above scenario - variable length.
WORDS and WORDNUM are not as big as GETWORDCOUNT() and GETWORDNUM(). Is that a real reason? I don't think so but you might.
Do you have any others?
Comments
Turns out this is an important difference when you are reading incoming POST header data in HTTP communications.
Good article thanks.