using application path (app.path) 
Author Message
 using application path (app.path)

First I would like to thank those who have given me suggestions about how
to streamline my ado controls. I get the general opinion that using the ado
object instead of separate controls is much less resource consuming. I will
consider it in the next "revision" of my application. for now, it is ok, i
just want it to run as efficiently as possible.

Another concern....

I am using the deployment wizard to create the installation disks for my
app. during the installation, it askes you for the path you want to install
it to (default = c:\program files)

the problem is that my app looks for 6 text files, 2 rtf files and one
major database file in a specific location. I would like to make it look
for the support files wherever the program is running from.

I plan on using the app.path to append the actual path of the application
to any location that accesses the files such as:

strFilename = app.path & "\junk.txt"

then use the variable strFilename in an open statement or whatever. Before
I commit to these changes (there are many times where it accesses external
files) I tested it and it seemed to work. Does anyone out there know of any
reason why I should NOT do it this way, please let me know NOW!!!!

I use a save file dialog box to save a report and this changes the
"default" location for files as I found out when originally I had no path
specified for the external file and the program kept looking for the file
in the "new" directory. then I switched to the full path name but I would
like it to work the way I described.

Also my (many) ADO controls all have their connection string set (at design
time) to that same exact path. I would have to redefine the control's
connection string during run time to also use the method of app.path &
"junk.mdb". Am I also correct in this assumption?

My only concern is that the app.path might change during the program, but
from what I have read, it is defined as the path from where the application
was run which should be wherever the person installed it.

My Question(s):

Am I on the right track with this method?
If not, any suggestions would be appreciated.

Thanks again
Steve Greenberg



Mon, 11 Apr 2005 10:49:06 GMT  
 using application path (app.path)
On Thu, 24 Oct 2002 02:49:06 GMT, Steve Greenberg

Quote:

>My only concern is that the app.path might change during the program, but
>from what I have read, it is defined as the path from where the application
>was run which should be wherever the person installed it.

>My Question(s):

>Am I on the right track with this method?
>If not, any suggestions would be appreciated.

If i understand correctly.. then yes.

The way i do this is that i set a global string HomePath or HomeDir
(name it what you like) that is set to the App.Path in Sub Main
initally.
When a user decides to work with a different set of data i simply
change HomeDir to whatver path they are using.
Then save this path to my ini file, or registry. The next time the app
starts up, this saved path is checked for validity, if the path and
required files do exist all is well, if not, then we default back to
App.Path, if that also fails, we ask the user for help with
BrowseForFolder or any other way to get at a valid data set..
Once this is over, in the code every reference to a file or folder is
then prepended.  Open HomeDir & whatfile.whatext etc..

As for App.Path changing mid flight.. that's news to me.
You mean Curdir perhaps ?

--
Regards, Frank



Mon, 11 Apr 2005 15:10:26 GMT  
 using application path (app.path)


Quote:
> On Thu, 24 Oct 2002 02:49:06 GMT, Steve Greenberg

>>My only concern is that the app.path might change during the program,
>>but from what I have read, it is defined as the path from where the
>>application was run which should be wherever the person installed it.

>>My Question(s):

>>Am I on the right track with this method?
>>If not, any suggestions would be appreciated.

> If i understand correctly.. then yes.

> The way i do this is that i set a global string HomePath or HomeDir
> (name it what you like) that is set to the App.Path in Sub Main
> initally.
> When a user decides to work with a different set of data i simply
> change HomeDir to whatver path they are using.
> Then save this path to my ini file, or registry. The next time the app
> starts up, this saved path is checked for validity, if the path and
> required files do exist all is well, if not, then we default back to
> App.Path, if that also fails, we ask the user for help with
> BrowseForFolder or any other way to get at a valid data set..
> Once this is over, in the code every reference to a file or folder is
> then prepended.  Open HomeDir & whatfile.whatext etc..

> As for App.Path changing mid flight.. that's news to me.
> You mean Curdir perhaps ?

> --
> Regards, Frank

Thanks for the info frank,

i don't think my app is complicated enough (yet) to use an ini file or
access the registry. I think the plan with the app.path will work fine for
this application. Yes I do believe now that the app.path is fixed and it is
the curdir that changes with the common dialog box.
All should work. I have already changed the references to the external text
and rtf files to use the app.path and it seems to work. Now I just have to
add a bunch (about 18) of connection string definitions for the ado
controls. I think eventually i will switch to the ado object instead of the
controls. I need to produce a "working" version to show the client ASAP. I
can make the refinements in a later version.

Thanks again

Steve



Mon, 11 Apr 2005 20:08:45 GMT  
 
 [ 3 post ] 

 Relevant Pages 

1. Paths and App.Path

2. App.Path only returning short path name - Why?

3. app.path only returns short path name

4. Help: App.Path returns 8.3 path in VB4/Win95

5. PATH-APP AND MDB-PATH

6. app-path and mdb-path

7. App.Path returns "short" path name

8. Changing Long Paths to Short Paths in a 16-bit App

9. Setting the path to the path of the current application

10. Application Setup Wizard Says D:\<path>\D:\<path>\target.exe

11. Enforce using DLL at specified path rather than at System path

12. Getting the app.path of the instantiating application - I think :-)

 

 
Powered by phpBB® Forum Software