Place: Microsoft, 9 Hillside Avenue, Waltham, MA USA.
Time: Tuesday, April 18, 1995 (Special Date)
Meeting: Doug Hennig: The VFP Data Dictionary

Place: Aquinas College, Newton, Massachusetts
Time: May 2, 3, 4, 15, 16; 9:30am - 4:30pm
Cost: $495 for BCS members paying by April 18. All others add $45.
Seminar: BCS & Flash Creative Mgt.: Visual FoxPro 3.0 Boot Camp
Description: Lecture style training encompassing all of the material in Flash Creative Management's, normally hands-on, advanced Visual FoxPro training courses. Workbook and study guides included.

Upcoming Visual FoxPro 3.0 Conferences

Scores of top developers from the FoxPro community will be presenting at the following highly recommended events.

Reply To: Dick Whetstone 73707.461@compuserve.com, or Debi Edwards (804) 498-8579
Event: Mid-Atlantic FoxPro Database Solutions Workshop
Dates: May 5th and 6th
Location: Chesapeake, VA - 20 minutes from the beach at Virginia Beach
Cost: $99 until ($110 after April 21)

Reply To: Valdis Matisons 70632.3172@compuserve.com, 800-265-1362 or 416-256-4337.
Event: FoxTeach
Dates: June 8,9,10
Location: Prince Hotel in Toronto, Canada.
Cost: $449 U.S. ($499 after April 15)

Reply To: Harvey Johnson 73737.3603@compuserve.com, 1-612-941-9820.
Event: Minneapolis FoxPro Users Conference
Dates: June 4-6
Location: Minneapolis convention center
Cost: $365 ($395 After May 1)

Non-Visible FoxPro

Reply To: Arnold Bilansky 71533.1031@compuserve.com

Microsoft User Group Relations (Mindshare) recently mailed me a two page paper. It begins as follows:

Introduction.

Welcome to For Developers Only, a new column written by Microsoft's Developer Division for the developer community. I'm writing this column to provide developers with a source of information on development trends and how to take advantage of them. Even though this column is written for developers, it's of interest to anyone who wants to learn more about what's possible in creating custom solutions today.

Microsoft's Developer Division and A New Mission.

Microsoft has always had a deep commitment to the developer community, starting with the introduction of the company's first product - Basic. Over the years, we've continued to produce leading-edge tools for our developers, such as Microsoft Visual Basic programming system and Visual C++ development system. Recently, the Developer Division's mission has been expanded with the goal of representing all Microsoft products that are relevant to developers. As part of this overall mission, the Developer Division also provides developers with a full range of education and training services. This new mission includes support for development with the Microsoft Office family of products.

The document concludes "Next Issue":

We've covered a good bit of ground today, but it was to give all of you an idea of how Office is now a great development tool in addition to being a great application suite. Over the next several issues we'll drill down and examine the four cornerstones that make this possible. Later, we'll discuss other issues of interest to developers, such as OLE, BackOffice, and component-based software design. Next issue we'll start by discussing Microsoft's key cross-application language, Visual Basic for Applications.

We Want Your Feedback.

This column is written for developers. We care about what you have to say, so let us know how we're doing or tell us what topics you want to see covered. To reach us send email to mindshar@microsoft.com.

See You Next Issue, Scott Horn.

Making Browse Key Faster Using Undocumented Syntax Requirements:

Reply To: Wayne Snyder 71754.15531@compuserve.com, or wayne_snyder@usconnect.columbia.com

At one time or another, almost everyone needs to do a lookup on address. The requirement I had was to allow the user to name a street, street type like DR, LN, PKWY, HWY, etc., street direction like E,W, N, S, as well as the house number to get to a browse screen. The user may want the browse to include all streets whose name begins with "CANNON" and whose street type is "BLVD", so that all properties for CANNON BLVD, CANNON TEMPLE BLVD, etc. would populate the browse window.

My solution was to use code like:

	SET EXACT OFF

	BROWSE FOR ;
		main.direction = m.direction AND ;
		main.streettype = m.streettype AND ;
		main.houseno = m.houseno ;
		KEY m.street

When running the program however, bad response became an issue. If I entered "CANNON" as the street name with everything else empty, response was fast. If I add 1 character to ANY other field, things got slower. Two characters made it slower still.

In trying to debug the problem I created a small function which always returned TRUE, but added one to a local variable. I put this function in the browse for clause so that after the browse was through, I could see how many records were being compared in the for clause of the browse. Sure enough, the more characters entered in houseno, for instance, the more records were being compared in the for clause, until a full table search was being performed. I knew that there were 100 records with a street name of "CANNON", but all 1 million records were being searched. This is not what I expected at all, but fortunately the solution is very simple.

Put the key clause in front of the for clause, and life will be good again. Imagine that!!!... I could not find any documentation which suggests the order of the clauses would make any difference, but it surely does. The good code looks like:

	BROWSE ;
		KEY m.street ;
		FOR main.direction = m.direction AND ;
		main.streettype = m.streettype AND ;
		main.houseno = m.houseno

Rolling Your Own Date Function - A Reply:

Reply To: Brad Schulz 76640.152@compuserve.com

Ted:

>>January 01, 1994

>>The only way to get rid of that is by rolling-your-own date function,
>>combining the cmonth(), str(), day(), and year() functions.

	STRTRAN(MDY(mydate)," 0"," ")

---

How To Avoid The DMF Blues:

Reply To: Ted Roche 76400.2503@compuserve.com

Rumor has it that Microsoft, faced with the largest upgrade of all times (Windows 9x) is looking into new technologies to cram more onto each diskette. One promising method is called DMF. Rather than compress the actual data, as PkZip and other methods do, DMF actually formats the disk in a different way, producing more tracks and sectors on which to put the data. This can be combined with a compression scheme to produce far more information per diskette.

As a veteran of similar techniques tried on the Commodore 64 (with its 170K SSSD drives), I would like to point out that there will probably be some incompatibilities on some machines, and offer some work-arounds. Differing timing between different peripherals, problems with drive head alignment and BIOS settings combine to make it nearly impossible for Microsoft to produce a new format easily used in all machines.

Key Point: Don't mess with the new format! Disk utility and virus checking programs, unless brand new, probably do not know how to use this format and will mangle the disk while telling you they are fixing it. Similarly, don't expect diskcopy to work, either. Write-protect the disks, and keep 'em that way.

First, the easiest way to try to read these disks is to force errors at each disk change by leaving the drive empty, which will reset the drive. Some drives with marginal timing or alignment can get by this way. Each time the machine asks for the next disk, remove the disk, select OK and when the machine reports an error, place the next disk in the drive and retry. It's ugly, but it works.

The obscure drivparm setting in the config.sys file is another easy change. Type HELP CONFIG.SYS at a DOS prompt and select the drivparm option for complete help for your version of DOS. For MS-DOS 6.x, add the line:

	DRIVPARM=/D:x /F:y

Still with me? You must be getting desperate by now. Hang in there, pardner. We ain't licked yet. Strip everything extraneous out of your config.sys and autoexec.bat. If you're not using a multi-boot utility, this is a real good time to look at one. Make sure to backup before wiping out old files. Reduce your file entries to the minimum necessary - skip the sound card and the CD-ROM drivers, smartdrv, but leave in himem, and see if you can read the floppies.

There is a program called fdform.zip available on CompuServe, in the IBMHW forum which contains several programs to make it easier to read these disks. These include utilities to copy the disks to a hard drive, or diskcopy the disks. I don't have any personal experience with them, but I have been told that they do the trick on some machines.

Finally, if all else has failed, find a friend with Win95 and get them to copy the disks to their hard drive. (Win95 reads the format natively). Use the extraction program on the disks to pull apart the files and PkZip'em onto a bunch of floppy disks.

Still stuck? Time to give up. The disks you've gotten may be bad - try to get a new set. Try another machine. Try to get a copy on CD-ROM. Try to get a "normal" high-density set. Try to get a set on low-density (yuck!) diskettes. Try to give Microsoft a hard time.

This new format could save Microsoft millions of disks, saving us all a few bucks and perhaps lowering our impact on the environment a smidgen or two. Anticipate better compatibility as the product gets closer to shipping, and some better utilities to help those of us with marginal machines.

Hardware Requirements For Visual FoxPro:

Reply To: Ted Roche 76400.2503@compuserve.com, Andy Neil [Micromega] 71053.2502@compuserve.com

One of the big unanswered questions in using Visual FoxPro is "what is the minimum and the desired hardware necessary for me as a developer?" I think we are all aware that software companies must advertise their products by stating the minimum platform it will run on, not necessarily the minimum platform on which it will run acceptably.

Andy Neil provided the following answers:

For Serious Development (Not End-users):

Big Fun: Pentium/100 w/64MB and 2GB, 4MB video and 21", running NT3.5

At this point, NT3.5 and at least a 17" monitor at 1024x768 are minimum requirements for a genuinely productive desktop VFP environment, IMHO.

---

Tips On The Transporter:

Reply To: Bill Dodson 74010.2413@compuserve.com
Download: FOXUSER/FOXGANG FOX0222.PPT

We spend a lot of time moving applications from PC to Macintosh and back again. Here are a few of the tips and tricks we've picked up in our cross-platform work with FoxPro. You'll find a PowerPoint presentation that discusses these and other experiences in the FoxGang library of the FoxUser forum on Compuserve. The name of the file is fox0222.ppt.

The FoxPro Transporter is not only the key to moving screen and report objects from Macintosh to PC and back again, it is also the door and passageway. So, there's no getting around it: you have to use the Transporter to move your work from one platform to another.

Basically, the Transporter creates object handles and coordinates that correspond to each of the platforms. Remember, FoxPro uses Foxels (not Pixels) as the units of measurement on both platforms. Foxels support up to three decimal places, and maintain the same proportions on either platform.

The transporter does a couple of other things, too: if you have moved a screen object from one platform to another - say, from PC to Mac - the transporter creates a duplicate set of records in the .scx file. The .scx file is actually a .dbf style data file in disguise; so you can actually browse the .scx file as you would any .dbf.

When you do browse the .scx file after transport to the Mac platform, you will see a set of records in which the value in the first field, PLATFORM, is "WINDOWS" (or "DOS", if you were moving from the DOS platform). As you scroll down the browse window you will see the first set of records transit into another set. The Transporter prefixes the second set of records with a "MAC" value to earmark the set of objects that will appear in the screen layout on the Macintosh. You'll also see that in addition to a unique identifier for every record-object (the UNIQUEID field), the Transporter has attached a timestamp (the TIMESTAMP field).

As you make changes to your screen on one platform and then move it to another platform, the Transporter first checks to see if there are any new objects for which it needs to create a new unique identifier. It then checks to see that all the other objects previously transported are of the same timestamp. If there are any objects with dissimilar timestamps, the Transporter regenerates all the objects for the new platform.

This can be tricky since you really ought to re-transport your screens after every edit cycle. Otherwise, it becomes difficult to keep track of the changes you've made on your primary development platform: a bug that crops up on the transport platform becomes harder to solve, since it could have been born several edit cycles before, buried under subsequent lines of code. Of course, this implies a fair amount of time lost with each transport; but the amount of time involved with each transport far outweighs the Gordian knot of bugs you will have to cut through if you wait on your transports.

Another observation we've made is that you must completely rebuild a screen on all its platforms if the Transporter begins displaying errors. It seems, the Transporter becomes confused as to what object belongs in what platform. During code generation, FoxPro displays spurious errors that hadn't appeared during the last generation.

If you delete an object in a screen and then draw or place that object again, the Transporter will perceive a completely new object, and so will regenerate the entire screen again. So try to be conservative in your object manipulations.

Here are some guidelines to follow when you transport objects from the Macintosh: Stick to eight character DOS naming convention on Mac. Arcane but saves lots of time. Avoid spacing in file and volume names. Fox for DOS and Windows won't be able to read the path inside the project that points to all the files in the project. Avoid placing a lot of code in snippets. There's a good reason for this: even without snippets, genscrn has to regenerate the code at least twice in a cross-platform transport. With snippets, .spr files really balloon in size, since the snippet are duplicated as well. What you'll want to do then is to place snippet code in generic .prg files, which neither go through the Transporter nor through the genscrn code generator. Certainly, this goes against the grain of what we know we need to do to try to ready our applications for the transition to Visual FoxPro. You'll have to be the final judge, then, on the efficacy of slimmer snippets in your applications.

One note on final transports: Delete the records in the .scx file that correspond to the platform you're leaving behind to reduce generation time and run-time. We do this for our Macintosh applications in which a Windows sub-contractor has done work and transported the product to Macintosh. When you delete the records in the .scx file for the platform you no longer need, genscrn does not generate programming code for that platform: no more .spr bloat; faster run-time; smaller .exe's.

---

References On Metrics:

Reply To: Grant D.H. McHerron grant@tiac.net

While generally oriented towards the large IS department or software houses, capturing metrics is something every developer should be involved in, even on single-programmer projects. Naturally, the scope and scale of the metrics being captured and analyzed will change depending on the size of the project and so on, after all, the idea is to monitor your work to help improve your development process, not get bogged down capturing unnecessary details.

For those who are interested in the finding out more about Software Metrics, the January issue of the Application Development Trends magazine has an article by Capers Jones covering the topic. The magazine is well worth reading and can be obtained free if you meet their subscription requirements.

I can definitely recommend reading the book Applied Software Measurement from Capers Jones to find out more about metrics. In the above article, Jones also recommends (among others):

Putnam, Larry, Measures for Excellence

His listing covered more titles so try to obtain the magazine if you want to see the rest.

---

Free Visual FoxPro 3.0 Upgrade Policy

Reply To: Arnold Bilansky 71533.1031@compuserve.com

From: Arnold Bilansky 71533.1031@compuserve.com
To: Cris Wittress (Microsoft)
Subject: VFP Upgrade Policy

AB: The press FoxPro DevCon press release stated that customers purchasing FoxPro after January 16 may qualify for a free upgrade to Microsoft Visual FoxPro 3.0. Is there a clear policy set for exactly what purchases qualify for a free upgrade?

CW: People who purchase 2.6 after 16 January until 3.0 ships will receive a free upgrade to 3.0 (standard to standard, pro to pro). They have to contact Microsoft with their proof of purchase to get it. The sentence you're referring to is the "legaleze" that we need to use to say this.

AB: What, if any, upgrades would qualify for a free upgrade? I would not be surprised to learn that the $19.95 upgrade from 2.5 to 2.6 would not qualify. What about the 2.5 standard upgrade to 2.6 professional edition? I asked inside sales, he said that the latter would qualify.

CW: Yes, the latter qualifies, not the former.

[Editor's Note: Only the Windows version qualifies for the free upgrade]

---

BCNN Statement Of Ownership, Copyright, And Responsibility

---