>Ed,
>
>I can definitely see the value of writing code that is free of any hard coded drive mappings, especially when writing code that is going to be comercially distributed. Using the registry or an INI file is definitley a slick way of doing this.
>
>I do still however stick to my original point. That point being that a good network design implementation in most organizations should be able to have standards and continuity (regardless of how an app has been written that exists on that network). A good deal of VFP programmers (and again, not all) do most of their programming on custom Apps that exist on one particular network. Being able to count on a standard drive mapping scheme among the app's users should be a common, achievable practice.
>
>Just because we can go to a lower common denominator (UNC pathnames) doesn't mean that we have to.

It's a matter of what we want to treat as an absolute reference. Unless more than one share hierarchy is needed, there's NO NEED for a drive letter reference, since VFP can CD/SET DEFAULT to a UNC or drive letter/path, and can incorporate UNC-based paths into a SET PATH statement.

Why not leave it as 'Store where things are supposed to live rather than hard-coding them', giving you the choice of how to make a path reference, and resolving the path at runtiome. If you must have drive mapping, it's trivial to map a drive from within VFP using the Win32API (you can see an example in my NETRESOURCE class that can be downloaded here on UT, using WNetAddConnection3()) or an automation object like the WSH Wscript.Network can do with the MapNetworkDrive method, or by invoking a command line mapper like NetWare's MAP or the MS Networking NET USE command via RUN or the Win32API.