JustPath, FoxPro way
When I upgraded to FoxPro 9 to gain additional enhancements, I had to re-write a great deal of code. Much of my work was based on an old FLL named Focus. Because Focus would not work with FoxPro 9, I had to use whatever FoxPro 9 provided and write a new FLL when FoxPro didn’t have what I needed.
One of my most-used functions in Focus uses an old DOS function to separate the drive letter, path, filename and extension from a file specification. FoxPro seemed to have exactly what I needed in the collection of the Justxxx() functions. So when I re-wrote the code in the HUD-1 form, I used those FoxPro functions.
This was a very bad mistake. I did not check to see if the result was the same for the Focus function as it is in the new FoxPro function. And the results are different. Here’s how:
If I put the following path into both functions:
C:\Full Length Movies\NORAD.911.TAPES
Here are the results I get back:
Focus: C:\Full Length Movies\NORAD.911.TAPES
FoxPro: C:\Full Length Movies
If I use this path:
C:\Full Length Movies\NORAD.911.TAPES\ (note the trailing slash)
Here are the results:
Focus: C:\Full Length Movies\NORAD.911.TAPES\
FoxPro: C:\Full Length Movies\NORAD.911.TAPES\
It’s obvious that, even though NORAD.911.TAPES is a folder, that JustPath strips it out of the returned path as though it were a filename. This gets even more odd when I try to get the extension using the JustExt() function. It returns .TAPES when it should return a blank string! And this is the problem.
These functions require a very tough programming standard, and I don’t always adhere to tough standards, even my own. Other programmers have the same habit.
So I have to make these functions a lot smarter. I propose to do this by extending my FLL with more file and directory functions. Along the way, I’ll also add a few other functions to extend and balance the new ones. Here’s the list of new functions:
APP_IsPath – is this a path to a folder?
APP_IsFile – is this a path to a file?
APP_JustDrive – just the drive letter and colon.
APP_JustFolder – Just the path w/o drive letter, filename or extension, otherwise unmodified.
APP_JustPath – Just the drive letter and folder path.
APP_JustFilespec – Just the filename, the period and extension.
APP_JustFilename – Just the filename, no period or extension.
APP_JustFileext – Just the extension, no period or filename.
The results of these functions will be absolutely predictable. If you put a path to a folder into the APP_JustFolder() or APP_JustPath() functions, you will get the correct answer, regardless if the path ends with a slash. The App_IsPath() and APP_IsFile() functions are added to provide upper-level access to the low level functions that support the others.
I plan on writing these functions and their support functions in a three-level tier structure. At the top are the above functions, which are really there to expose the second tier functions to FoxPro. The second tier accepts calls from the first tier, passes the parameters to the single third-tier function, and interprets the results. Tier two then passes the results back to the top tier which sends the results back to FoxPro.
This is a fairly common approach for me, as I have written a lot of my structure interface code this way. It has two advantages: a common interface and expectations between FoxPro and C using multiple C functions and direct invocation by C level code of the entire second tier by other functions in the FLL. The third tier code calls various Win32 and Shell functions and fills in a structure that is passed from above. All the functions in the second tier use information provided by the third tier to greater or less extent.
There is one additional upper-level function I’ve proposed, but it will have to wait until I resolve some problems with returning strings to reference variables. Or I might use the FoxPro STRUCT class to create a structure that can be passed back to a calling method. This would be an upper-level function and be named APP_FileInfo().