Re: Re-Post: Project Path References

Also (and I'm sure you're aware of this, but I figure for the sake anyone
using this as an answer to their own problems, I'll say it anyway) be sure
that when you distribute your app that the directory structure in the
distributed program's folder stays the same as it is on your harddrive
(I.E. all non included files, such as images, dlls, etc) need to be in the
project folder or a SUBFOLDER of the project folder, if you're going to use
relative paths, and need to be distributed while keeping that structure
intact.

Just dumping all the files into the program's own directory won't always
work if it's specifically looking for /subfolder/something.dll (although
that reminds me - if you absolutely HAVE to do a quick and dirty test of a
program on a non-vfp machine without using an install set or registering
the runtimes in system32, you CAN just dump the runtimes into your program
directory and it'll work. I don't recommend this for ANYTHING other than a
quick test on an unregistered machine if you're in a big hurry. And that
scenario's not very often. And it adds about 17 megs to the folder size.
Ouch.)

Well, I'm off my tangent, so y'all have a great afternoon! Hope you get the
program up and running.

Cheers!
-LS

"Tim Oister" <tjoister@xxxxxxxxx> wrote in
news:58udnWDnYOyHfq3bnZ2dnUVZ_gWdnZ2d@xxxxxxxxxxx:

Thanks Bill!

I'll take advantage of the SET PATH command, and it won't be all that big
of
a change, because I store all of the application paths in a control
table,
so that I can logically switch the code when running in a development or
production environment. It will just be a matter of creating the path
string.

I believe that what tripped me up on this whole thing was having a
different
directory structure in the production and development environments. As
someone said in my intial post above, the APP apparently doesn't resolve
the
paths the same way a compiled EXE does, so I'll add the SET PATH
information.

Thanks again!



.