>
>I agree with the principle (though I don't use it - my apps always
>install below \app :) - but then we are installing them and not making
>floppies, using the time for configurations and user education), and it
>seems to be quite commonly accepted in Windows (and DOS, for the
>matter), with the app's liberty of creating subdirectories below the one
>user chose taken for granted. Installing it on a local or networked
>directory didn't change much, but, OTOH, I've never done a full app in
>VFP, and never tried install. When I come to the installation issues,
>I'll surely shout here :)

Dragan,

If the app resides on a network, then standardization, for the purposes of maintenance, is highly desirable. I've got around 40 apps to maintain (in FPW and being ported to VFP 5.0) that are at 7 different locations, both here in the states and overseas. I would have gone bonkers (some say I already have) with standardized directories.

My situation, the apps a manufacturing environment without a high degree of traffic or contention, allows me to use this design. However, if the app(s) resided locally (for whatever reason), then I would allow the user to define the "home" directory, but not the children. While the speed increase you get from reducing the number of files in a directory isn't much of a factor these, since my systems have a rather open architecture (user's can access and modify reports) this sort of strategy is beneficial to them. Further, I believe this practice is common with most commercial software packages.

George