The LA Fox Developer Newsletter

August 1997

Environment (Con't from page 3)

instantiate them by yourself then you can do all your SETs in the form’s Load Event instead (again before you open any tablet view). An example of why it is important to do the SETs before you open tables is SELECT or parameterized views that are effected by the state of SET ANSI,SET EXACT, SET NEAR etc.

A good way to handle this is to create a class that will do all the needed SETs and just instantiate it at runtime in its simplest way it can look something like:

DEFINE CLASS myENV1 as CUSTOM

PROCEDURE Init

SET TALK OFF

SET EXACT OFF

&& etc.

ENDPROC

ENDOEFINE

A better way however would be to create a property for each SET command and add methods that will handle mass SETs (for global and private use). Also, you don’t want to forget to reset them to the original values after you’ve finished with them. I will upload to the VFUG files section an example of such a class over the next couple of days. My version has 2 properties for each SET command (on for old value and one for current value ) and uses the following EVENTS and METHODS:

SET(tcSetname,tuValue,tlSaveold) - Will set a specific set command according to the value passed and will save the old value if requested. RESET(tcSetName) - Will reset a SET to its older value. SELALL() - Does just what its name implies. SETGLOBALO - Set only the Global SET commands. SETPDO

- Set the SET commands scoped to the datasession. RESETALLO - Will reset all the SETs that has a value saved. INIT() - Call’s the appropriate method ,SETALL,SETGLOBAL or SETPD depending on a property. DESTROVO - Calls the RESETALLO method.

This is just what I created you can easily create a similar or more simple/complex class to fit your needs.

I hope this short article has helped you the get familiar with yet one of more VFPs behaviors, in any case I would love to get comments on what you think on this article and/or subjects you would like to see me cover in future newsletters.

Don’t Forget!!

September’s meeting will be held on

September 22, 1997, at 7:30 PM, due to

a conflict with the San Diego FoxPro

Developer’s Conference.

Finding the Drives on a System

by Charlie Parker, Rocky Mountain PUG

I recently wrote a program that accesses a CD-ROM to get graphics and sound files. One of the challenges I had was just finding the CD-ROM drive. I found the easiest way to do this was to use the Windows API functions to determine the drives and drive types on any system. To test out the functions, I wrote a small program that just lists the drives that are available on a system. Although the particular program is probably not something you will use directly, it does demonstrate how to use the Windows API function for this purpose.

One note of caution: Any drive that has “removable” disks is returned as a type 2 drive. This includes SyQuest drives and ZIP drives as well as floppy disk drives. So, if you are looking specifically for a floppy disk drive, you will need to do some additional checking to ensure that you are not looking at a SyQuest drive or Zip drive.

Here is the program:

This is a sample program to show how

Visual FoxPro. It uses the

*_ GetLogicalDrives API function to determine which drives are set up on

the system. Then, for each valid

drive, it uses the GetDriveType API

drive (e.g. hard disk, floppy,

*_ CD-ROM, etc.) it is.

CLEAR

LOCAL lcDriveLetter, lnValidDrives,

InCounter, IcMsg, InDriveType

*_ Declare the Get Drive Type Windows

*_ API routine. DECLARE INTEGER GetDriveType; IN KERNEL32.DLL STRING

Windows API.

DECLARE INTEGER GetLogicalDrives

IN KERNEL32.DLL

*_ Call the Get Logical Drives

*_ function. lnValidDrives GetLogicalDrives()

*_ Loop through the returned value and

*_ check each bit to see which drives

*_ are valid (bit 0 = A, bit I = B,

is a drive associated with that

letter.

FOR InCounter = 0 to 25

(Con’t, page 8)

Page 4