April2000

The LA Fox Developer Newsletter

SETUP WEIRDNESS RESOLVED

by Mike Copeland and Matt Galloway

The Visual Foxpro 6.0 Setup wizard has some undocumented behaviorthat you should be aware of. While this behavior is not wrong, if you aren’t aware of it, you might gettripped up.

-Problem- After running SETUP on an end-user PC, you may notice that

some files were not copied from your Setup discs to their hard drive. Specifically, this pertains to the EXE, DLL, and FLL file types.

-Why- Windows-style internal version numbers are not stored in I 6-bit

program files, including program files generated by Visual Foxpro 3 and any executabtes that are compatible with Windows 3.1 . On the other hand, when 32-bit application files that adhere to the Windows standard are compiled, they always have internal space created forversion numbers. The Setup application thatVisual Foxpro 6 creates, (via TOOLS I WIZARD I SETUP in Visual Foxpro), checks for these internal version numbers when your end user runs Setup from your installation disk(s). While not documented anywhere we could find, it seems that the version numbers for both existing and to-be- installed files are collected during Setup. These version numbers are matched according to file names, compared, and the highest version number wins; that file is either retained or copied to the destination disk. Note that the file date and time stamp and the file size do not seem to be considered. lfthe file does not exist, the new file will always be installed. If a 32-bit file does not have a version number, it appears that Visual Foxpro considers it as having a version value equivalentto 0 and compares values accordingly.

Since there is no way to instruct Setup to delete or ignore a file you intend that Setup should replace, the only solution is to always increment your application’s version number to a higher value. Failure to do this will cause SETUP to skip overwriting the old file that already exists on your end-user’s hard drive with the new one you sent them on disk (and that you probably intended to have serve as an update.) You’ll notice that the version number, entered from within Visual Foxpro via the PROJECT I BUILD I VERSION menu options, is numeric only. This non-alpha restriction for the version number reinforces the above understanding ofthe way Setup works.

-Other Observations- This also means that your end user will have to manually delete

a corrupted EXE, OLL, or FLL file before running Setup. A corrupted file might still have enough information in the header to provide a version number, but not execute properly. And, while the Reinstall feature is promising, we have found that Setup’s -Reinstall/Remove-functionality is sometimes hit-or- miss. Sometimes when you run Setup (and the application is already installed), it may or may not offer the Reinstall option. Something as simple as hitting escape during the Reinstall

routine will cause the Reinstall option to not be offered the next time you run Setup. I’m sure there is a perfectly good explanation for this behavior, but it is hard to explain to end users.

Sending update discs containing your Visual Foxpro 6 application is still the easiest and least expensive way to distribute your programs. But, making sure you use, and increment, the version number of your application is more than just a good idea, it’s required...or you may not get what you expect.

<mike.copeland@genesis-group.net>

Mike Copeland is an independent FoxPro developer (Genesis Group Software) in Bartlesville, Oklahoma. His Fox credentials go back to being Technical Editor for Y. A. Griver’s “The FoxPro Code Book”, which preceded the Codebook framework.

<matt.galloway@oden-ins.com>

Matt Galloway is Directory of Technology at ODEN Insurance

Services, Inc. They are in Tulsa, Oklahoma, and market

FoxPro applications to the insurance industry.

From Dan “The Man”...

Found this gem in one of the newsletters I get. <>Dependency Walker v2.0b5 [409k] W9x/NT FREE http://www.dependencywalker.com/ http://www.dependencywalker.com/depens20beta5_x86.zip

“Dependency Walker is a free Microsoft utility that scans any 32-bit or 64-bit Windows module (exe, dll, ocx, sys, etc.) and builds a hierarchical tree diagram of all dependent modules. For each module found, it lists all the functions that are exported by that module, and which of those functions are actually being called by other modules. Another view displays the minimum set of required files, along with detailed information about each file including a full path to the file, base address, version numbers, machine type, debug information, and more.”

[It’s a 420k download. YOU NEED THIS PROGRAM!! DC)

TOOLTIPS FOR FOLDERS

I remember that a few months ago we were discussing the problems of keeping track of what’s in all those directories on the hard drive, and I said “What I’d like to see is ToolTips on the Folders.” If the folder name is IBX3I, you could hold the mouse over it and see that it was “Ibex Corp’s software for 31-bit mouse reversers” or something like that. Well guess what, you can do it!

The following technique works in Windows 98 and Windows 2000; it doesn’t work on NT 4.0 or Win 95.