|
List Info
Thread: App.Path Property
|
|
| App.Path Property |
 
United Kingdom |
2007-07-24 03:28:31 |
|
Hello Steve,
Sorry I haven't replied to you emails before now.
My laptop, where your emails are, had to go for doctoring yesterday and I can't
get to them at present.
In the meant time, I was hoping that a number of
files could be grouped together, so that the files could be read by a program,
even if they had got moved.
I have realised since asking that original
question, that it doesn't work like that. However the example I had does not
seem to work, in that if I do move the .txt files, I get a error message
something to the effect that the files can't be found.
I've looked around for the examples I had to refer
to, but, so far, I can't find them.
I have understood that the App.Path Object/Property
works with the program's path to the file(s), but I must be misunderstanding something, because I can't get it to
work.
Any help in finding examples to work with would be
appreciated.
If I was to look up the Microsoft Knowledge Base,
what would I search on. BTW. The MSDN Library doesn't seem to have any
information about the App.Path, at least, not that I can find.
Thanks for any help.
All the best,
Geoff
__._,_.___
.
__,_._,___
|
| Re: App.Path Property |
 
United States |
2007-07-24 04:53:36 |
|
I've been following this thread a little, hope I will not re-hash what
has already been stated. =;)
If you have all the .txt files in your programs directory, only then will
App.Path work ie... Open App.Path & "NameOfFile.Txt" for
Input As #1
If the files however have been moved from this location you will have to
search for them. You could have a number of was to do this. For
simplicity, say you have a file in the App.Path location you could open
this file and get the file names and then search for these files one by
one.
This example uses a API to search.
NOTE: For some reason the "SearchTreeForFile" API does not
search the OS directory!
(Watch out for EMAIL wrapping the text below)
Private Declare Function SearchTreeForFile Lib "imagehlp"
(ByVal RootPath As String, _
; ; ; ; ; ; ;
ByVal InputPathName As String, _
; ; ; ; ; ; ;
ByVal OutputPathBuffer As String) As Long
Private Const MAX_PATH = 260
Private Sub Search_For_Files()
Dim tempStr As String, Ret As Long, strTmp As String
Open App.Path & "Names.Txt" for Input As #1
;
Do While Not EOF(1)
; Line Input #1, strTmp
;
; 'create a buffer
string
tempStr =
String(MAX_PATH, 0)
;
; ' returns 1 when
successfull, 0 when failed
; Ret =
SearchTreeForFile("c:", strTmp, tempStr)
; If Ret <> 0
Then
; ;
MsgBox "Located file at " + Left$(tempStr, InStr(1, tempStr,
Chr$(0)) - 1)
; ;
'// Here you could do what ever you want to the found file
; Else
;
MsgBox "File not found!"
; End If
; Loop
Close
End Sub
Better yet, You could also use the FindFirstFile and FindNextFile API to
do the search
I hope I have not muddied the waters here! =;)
Kenny
At 04:28 AM 7/24/2007, you wrote:
Hello
Steve,
Sorry I haven't replied to you emails before
now. My laptop, where your emails are, had to go for doctoring yesterday
and I can't get to them at present.
In the meant time, I was hoping that a number
of files could be grouped together, so that the files could be read by a
program, even if they had got moved.
I have realised since asking that original
question, that it doesn't work like that. However the example I had does
not seem to work, in that if I do move the .txt files, I get a error
message something to the effect that the files can't be found.
I've looked around for the examples I had to
refer to, but, so far, I can't find them.
I have understood that the App.Path
Object/Property works with the program's path to the file(s),
but I must be misunderstanding something,
because I can't get it to work.
Any help in finding examples to work with would
be appreciated.
;
If I was to look up the Microsoft Knowledge
Base, what would I search on. BTW. The MSDN Library doesn't seem to have
any information about the App.Path, at least, not that I can find.
Thanks for any help.
All the best,
Geoff
![[]](http://geo.yahoo.com/serv?s=97476590/grpId=1925883/grpspId=1705115364/msgId=19836/stime=1185265789)
__._,_.___
|
| Re: App.Path Property |
United States |
2007-07-24 08:19:57 |
|
Good morning Geoff. This is a very interesting discussion.
What about if you simulate grouping through your code? In other words,
there would have to be one master file that is searched for. Through
code, you could return that path of that file. Then find the other files
associated with your program, and move them to that same directory. The
one catch would be that the program names for the files would need to be
unique, so that the code would not accidentally grab another file of the
same name and move it to the new location.
> Hello Steve,
>
> Sorry I haven't replied to you emails before now. My laptop, where your
>; emails are, had to go for doctoring yesterday and I can't get to them at
> present.
>
>; In the meant time, I was hoping that a number of files could be grouped
> together, so that the files could be read by a program, even if they had
> got moved.
>
> I have realised since asking that original question, that it doesn't work
>; like that. However the example I had does not seem to work, in that if I
> do move the .txt files, I get a error message something to the effect that
>; the files can't be found.
>
> I've looked around for the examples I had to refer to, but, so far, I
> can't find them.
>
> I have understood that the App.Path Object/Property works with the
> program's path to the file(s), but I must be misunderstanding something,
> because I can't get it to work.
>
> Any help in finding examples to work with would be appreciated.
>
> If I was to look up the Microsoft Knowledge Base, what would I search on.
> BTW. The MSDN Library doesn't seem to have any information about the
> App.Path, at least, not that I can find.
>
> Thanks for any help.
>
> All the best,
>
> Geoff
__._,_.___
.
__,_._,___
|
| RE: App.Path Property |
United States |
2007-07-24 08:54:34 |
|
Good Morning Geoff,
VB-6
My earlier e-mails just explained that the App.Path
property contained the full file path to the
folder that stores our program, and other files:
C:Program FilesOur Program
App Path provides the current folder location of our program.
Every once-in-a-purple-moon the right side slash is missing.
It is a good programming practice to make sure that
the last character in the app path string is a backward slash.
As Adelle has mentioned, there are several reasons why we
should also plan on checking for doubled-up path slashes
when we create any file path string.
I still run a new path string through a small routine
that removes excess path slash characters, because
I have found several ways to mess this up < g >
Grouping:
-------------
Not sure exactly what you mean by this, but I normally
keep the data files 'grouped together' within a
sub-folder of the Program's Home Folder ( App.Path ).
If we are planning on doing some code that will search
a hard drive for every JPEG image file, and either
record its location, or make a copy and move that copy
into a new folder, I have not addressed that
in my earlier e-mails.
A Few Things About Sub-Folder and the Data Files:
---------------------------------------------------
1) The files may not be missing.
There may be a mistake in spelling, a typo, et cetera.
A slight mistake in typing-in the file name can make
things appear as if many bad things have happened.
2) If the sub-folder and the files are actually missing,
then they may have been deleted, renamed, all bad.
3) If the error is that the folderfile cannot be found,
ask the User to check their machine for the data files,
or to contact their supervisor. Tell them that your
program will resume when they have found the folder.
4) Sometimes number three is not an acceptable option
because the User has not entered the file's path.
( Our code may be responsible finding and processing )
If there are no User entry errors, then we may be
safe in assuming that the folder and files have
gone missing, disappeared, or met some untimely end.
5) In this case our error handler will make us use our
back-up folder, which we update every time we process
a new data file. If that does not work out, then
we might want to search for our 'hidden back-up folder'.
6) If all of our back-up folders are missing, then we must
ring the alarm bells, and tell the User to have their
IT dept correct the problem, or to pay us for a site visit.
7) I have never written any code to search the entire machine
for any files that some clueless idiot has 'moved'.
In fact, this is one of the points that are covered
when the Money Payer signs off on everything.
8) However, others may find themselves in a situation where
my approach is not viable, and I wish them luck if they
cannot access a proper back-up of the data, or if they
are forced to do a free visit, or if they must write
the code to search the maze. Remember, everything may
still exist on the machine, in a 'new' location, and/or
may exist with a new name, a new identity, just because
some devious User watched a movie about 'Witness Protection'
and now wants a longer coffee break.
Summary:
----------
If the data folder has gone missing, create a new 'original'
folder from our back-up folder, and make sure to include the
new data file that the User has just asked you to process.
Consider re-naming any new Data Folder, and Back-Up folder,
with a date and time stamp included in the file name, and
also update the place where we store the current
folder names to reflect these changes.
All The Best,
Steve
.
Sent Out at 09:54 AM EST Tuesday, July 24, 2007
.
.
________________________________________
From: helpwithvb%40yahoogroups.com">helpwithvb yahoogroups.com
[mailto: helpwithvb%40yahoogroups.com">helpwithvbyahoogroups.com] On Behalf Of geoff Smith
Sent: Tuesday, July 24, 2007 4:29 AM
To: helpwithvb%40yahoogroups.com">helpwithvbyahoogroups.com
Subject: [helpwithvb] App.Path Property
Hello Steve,
Sorry I haven't replied to you emails before now. My laptop, where your
emails are, had to go for doctoring yesterday and I can't get to them at
present.
In the meant time, I was hoping that a number of files could be grouped
together, so that the files could be read by a program, even if they had got
moved.
I have realised since asking that original question, that it doesn't work
like that. However the example I had does not seem to work, in that if I do
move the .txt files, I get a error message something to the effect that the
files can't be found.
I've looked around for the examples I had to refer to, but, so far, I can't
find them.
I have understood that the App.Path Object/Property works with the program's
path to the file(s), but I must be misunderstanding something, because I
can't get it to work.
Any help in finding examples to work with would be appreciated.
If I was to look up the Microsoft Knowledge Base, what would I search on.
BTW. The MSDN Library doesn't seem to have any information about the
App.Path, at least, not that I can find.
Thanks for any help.
All the best,
Geoff
.
__._,_.___
|
| RE: App.Path Property |
United States |
2007-07-24 10:39:37 |
|
Excellent points Steve.
I could not help but laugh when I go to the part about:
"that some clueless idiot has 'moved'"
Now my cube-partner thinks that I have totally lost my mind.
>
>; Good Morning Geoff,
>
> VB-6
>; My earlier e-mails just explained that the App.Path
> property contained the full file path to the
> folder that stores our program, and other files:
>
> C:Program FilesOur Program
>
> App Path provides the current folder location of our program.
>
>; Every once-in-a-purple-moon the right side slash is missing.
>
>; It is a good programming practice to make sure that
>; the last character in the app path string is a backward slash.
>
> As Adelle has mentioned, there are several reasons why we
> should also plan on checking for doubled-up path slashes
> when we create any file path string.
>
> I still run a new path string through a small routine
> that removes excess path slash characters, because
> I have found several ways to mess this up < g >
>;
> Grouping:
> -------------
> Not sure exactly what you mean by this, but I normally
> keep the data files 'grouped together' within a
> sub-folder of the Program's Home Folder ( App.Path ).
>
> If we are planning on doing some code that will search
> a hard drive for every JPEG image file, and either
> record its location, or make a copy and move that copy
>; into a new folder, I have not addressed that
>; in my earlier e-mails.
>
>; A Few Things About Sub-Folder and the Data Files:
> ---------------------------------------------------
>
> 1) The files may not be missing.
> There may be a mistake in spelling, a typo, et cetera.
> A slight mistake in typing-in the file name can make
>; things appear as if many bad things have happened.
>
> 2) If the sub-folder and the files are actually missing,
> then they may have been deleted, renamed, all bad.
>;
> 3) If the error is that the folderfile cannot be found,
> ask the User to check their machine for the data files,
> or to contact their supervisor. Tell them that your
>; program will resume when they have found the folder.
>
> 4) Sometimes number three is not an acceptable option
> because the User has not entered the file's path.
> ( Our code may be responsible finding and processing )
> If there are no User entry errors, then we may be
> safe in assuming that the folder and files have
>; gone missing, disappeared, or met some untimely end.
>;
> 5) In this case our error handler will make us use our
> back-up folder, which we update every time we process
> a new data file. If that does not work out, then
>; we might want to search for our 'hidden back-up folder'.
>
>; 6) If all of our back-up folders are missing, then we must
>; ring the alarm bells, and tell the User to have their
> IT dept correct the problem, or to pay us for a site visit.
>
> 7) I have never written any code to search the entire machine
> for any files that some clueless idiot has 'moved'.
> In fact, this is one of the points that are covered
> when the Money Payer signs off on everything.
>
> 8) However, others may find themselves in a situation where
> my approach is not viable, and I wish them luck if they
>; cannot access a proper back-up of the data, or if they
>; are forced to do a free visit, or if they must write
> the code to search the maze. Remember, everything may
> still exist on the machine, in a 'new' location, and/or
> may exist with a new name, a new identity, just because
> some devious User watched a movie about 'Witness Protection'
> and now wants a longer coffee break.
>
> Summary:
> ----------
> If the data folder has gone missing, create a new 'original'
> folder from our back-up folder, and make sure to include the
> new data file that the User has just asked you to process.
>
>; Consider re-naming any new Data Folder, and Back-Up folder,
> with a date and time stamp included in the file name, and
> also update the place where we store the current
> folder names to reflect these changes.
>
>; All The Best,
> Steve
> .
> Sent Out at 09:54 AM EST Tuesday, July 24, 2007
>; .
> .
> ________________________________________
> From: helpwithvb%40yahoogroups.com">helpwithvbyahoogroups.com
> [mailto: helpwithvb%40yahoogroups.com">helpwithvbyahoogroups.com] On Behalf Of geoff Smith
> Sent: Tuesday, July 24, 2007 4:29 AM
> To: helpwithvb%40yahoogroups.com">helpwithvbyahoogroups.com
> Subject: [helpwithvb] App.Path Property
>
>; Hello Steve,
>
> Sorry I haven't replied to you emails before now. My laptop, where your
>; emails are, had to go for doctoring yesterday and I can't get to them at
> present.
>
> In the meant time, I was hoping that a number of files could be grouped
> together, so that the files could be read by a program, even if they had
> got
> moved.
>
> I have realised since asking that original question, that it doesn't work
>; like that. However the example I had does not seem to work, in that if I
> do
> move the .txt files, I get a error message something to the effect that
>; the
> files can't be found.
>
> I've looked around for the examples I had to refer to, but, so far, I
> can't
> find them.
>
> I have understood that the App.Path Object/Property works with the
> program's
> path to the file(s), but I must be misunderstanding something, because I
> can't get it to work.
>
> Any help in finding examples to work with would be appreciated.
>
> If I was to look up the Microsoft Knowledge Base, what would I search on.
> BTW. The MSDN Library doesn't seem to have any information about the
> App.Path, at least, not that I can find.
>
> Thanks for any help.
>
> All the best,
>
> Geoff
> .
>
>
__._,_.___
.
__,_._,___
|
| Re: App.Path Property |
United States |
2007-07-24 11:12:36 |
|
Geoff...one question that would figure in your
situation is "Who creates these files?" If they are created by others (not the
end user) then you might would want to set them as hidden so only certain people
know where they are. If the program user creates the documents then
you can set your save button to a specific file location and do not allow them
to pick a location. As a quick get on the same page are you referring to
files (as in folders) or do you mean documents within the folders? They can be
handled differently. Hope I have not opened another hornet
nest.
Bob
----- Original Message -----
Sent: Tuesday, July 24, 2007 1:28
AM
Subject: [helpwithvb] App.Path
Property
Hello Steve,
Sorry I haven't replied to you emails before now.
My laptop, where your emails are, had to go for doctoring yesterday and I
can't get to them at present.
In the meant time, I was hoping that a number of
files could be grouped together, so that the files could be read by a program,
even if they had got moved.
I have realised since asking that original
question, that it doesn't work like that. However the example I had does not
seem to work, in that if I do move the .txt files, I get a error message
something to the effect that the files can't be found.
I've looked around for the examples I had to
refer to, but, so far, I can't find them.
I have understood that the App.Path
Object/Property works with the program's path to the
file(s), but I must be misunderstanding
something, because I can't get it to work.
Any help in finding examples to work with would
be appreciated.
If I was to look up the Microsoft Knowledge Base,
what would I search on. BTW. The MSDN Library doesn't seem to have any
information about the App.Path, at least, not that I can find.
Thanks for any help.
All the best,
Geoff
__._,_.___
.
__,_._,___
|
| Re: App.Path Property |
United States |
2007-07-24 11:33:15 |
|
Steve...Could the program assign special
permissions to the files and prevent the moving or (????) whatever from being
done by assigning a password known only to selected users before any action
could be taken? I am not sure if VB has code that would allow this so this may
be just another misguided random thought. Also, ;are the questions
pertaining to an actual program application or text type files used by a
different application and we are talking about directory problems?
----- Original Message -----
Sent: Tuesday, July 24, 2007 6:54
AM
Subject: RE: [helpwithvb] App.Path
Property
Good Morning Geoff,
VB-6
My earlier e-mails just explained
that the App.Path
property contained the full file path to the
folder
that stores our program, and other files:
C:Program FilesOur
Program
App Path provides the current folder location of our
program.
Every once-in-a-purple-moon the right side slash is
missing.
It is a good programming practice to make sure that
the
last character in the app path string is a backward slash.
As Adelle
has mentioned, there are several reasons why we
should also plan on
checking for doubled-up path slashes
when we create any file path string.
I still run a new path string through a small routine
that removes
excess path slash characters, because
I have found several ways to mess
this up < g >
Grouping:
-------------
Not sure exactly
what you mean by this, but I normally
keep the data files 'grouped
together' within a
sub-folder of the Program's Home Folder ( App.Path
).
If we are planning on doing some code that will search
a hard
drive for every JPEG image file, and either
record its location, or make a
copy and move that copy
into a new folder, I have not addressed that
in
my earlier e-mails.
A Few Things About Sub-Folder and the Data
Files:
---------------------------------------------------
1)
The files may not be missing.
There may be a mistake in spelling, a typo,
et cetera.
A slight mistake in typing-in the file name can make
things
appear as if many bad things have happened.
2) If the sub-folder and
the files are actually missing,
then they may have been deleted, renamed,
all bad.
3) If the error is that the folderfile cannot be
found,
ask the User to check their machine for the data files,
or to
contact their supervisor. Tell them that your
program will resume when they
have found the folder.
4) Sometimes number three is not an acceptable
option
because the User has not entered the file's path.
( Our code may
be responsible finding and processing )
If there are no User entry errors,
then we may be
safe in assuming that the folder and files have
gone
missing, disappeared, or met some untimely end.
5) In this case our
error handler will make us use our
back-up folder, which we update every
time we process
a new data file. If that does not work out, then
we
might want to search for our 'hidden back-up folder'.
6) If all of our
back-up folders are missing, then we must
ring the alarm bells, and tell
the User to have their
IT dept correct the problem, or to pay us for a site
visit.
7) I have never written any code to search the entire
machine
for any files that some clueless idiot has 'moved'.
In fact,
this is one of the points that are covered
when the Money Payer signs off
on everything.
8) However, others may find themselves in a situation
where
my approach is not viable, and I wish them luck if they
cannot
access a proper back-up of the data, or if they
are forced to do a free
visit, or if they must write
the code to search the maze. Remember,
everything may
still exist on the machine, in a 'new' location,
and/or
may exist with a new name, a new identity, just because
some
devious User watched a movie about 'Witness Protection'
and now wants a
longer coffee break.
Summary:
----------
If the data folder has
gone missing, create a new 'original'
folder from our back-up folder, and
make sure to include the
new data file that the User has just asked you to
process.
Consider re-naming any new Data Folder, and Back-Up
folder,
with a date and time stamp included in the file name, and
also
update the place where we store the current
folder names to reflect these
changes.
All The Best,
Steve
.
Sent Out at 09:54 AM EST
Tuesday, July 24,
2007
.
.
________________________________________
From:
helpwithvb%40yahoogroups.com">helpwithvbyahoogroups.com
[mailto: helpwithvb%40yahoogroups.com">helpwithvbyahoogroups.com]
On Behalf Of geoff Smith
Sent: Tuesday, July 24, 2007 4:29 AM
To: helpwithvb%40yahoogroups.com">helpwithvbyahoogroups.com
Subject:
[helpwithvb] App.Path Property
Hello Steve,
Sorry I
haven't replied to you emails before now. My laptop, where your
emails are,
had to go for doctoring yesterday and I can't get to them
at
present.
In the meant time, I was hoping that a number of
files could be grouped
together, so that the files could be read by a
program, even if they had got
moved.
I have realised since
asking that original question, that it doesn't work
like that. However the
example I had does not seem to work, in that if I do
move the .txt files, I
get a error message something to the effect that the
files can't be
found.
I've looked around for the examples I had to refer to,
but, so far, I can't
find them.
I have understood that the
App.Path Object/Property works with the program's
path to the
file(s), but I must be misunderstanding something, because I
can't get
it to work.
Any help in finding examples to work with would be
appreciated.
If I was to look up the Microsoft Knowledge Base,
what would I search on.
BTW. The MSDN Library doesn't seem to have any
information about the
App.Path, at least, not that I can
find.
Thanks for any help.
All the
best,
Geoff
.
__._,_.___
.
__,_._,___
|
| Re: App.Path Property |
United States |
2007-07-24 15:54:36 |
|
Geoff...Here is some info I have from my help
files. I do not know if it will work for you but it may spark some ideas.
I use the Office 2000 developers lib and this is some of what it says. Basically
it shows how to use the "File search" box in your application.
Searching for files is
something you may do over and over again in any number of different Office
solutions. This makes the FileSearch object a great candidate for
encapsulation in a class module that could be used in any Office solution that
requires file-searching capabilities. The ExcelExamples.xls sample file in the
ODEToolsV9SamplesOPGSamplesCH06 subfolder on the Office 2000 Developer
CD-ROM shows one way to use a custom class that uses the FileSearch
object. The sample file uses the dialog box in Figure 6.2 to gather information
about a search from the user.
Figure 6.2 Dialog Box Used to Gather Custom Search
Criteria ; (Picture shows the MS file
search form)
The Find Office Files dialog box is shown immediately after executing a
search for files with an ".xls" extension in the "c:my documents" directory.
Code behind the Find Matching Files command button uses a global variable named
objFileInfo to call the
GetFileList method of the custom clsGetFileInfo class as follows: Sub UpdateFileList()
' If the file-search specifications are valid, update
' the files contained in the form's combo box with a current
' list of matching files.
Dim varFoundFiles As Variant
Dim varFile ; As Variant
varFoundFiles = objFileInfo.GetFileList
If IsArray(varFoundFiles) Then
; With Me
;
.cboMatchingFiles.Clear
; For Each varFile In varFoundFiles
; .cboMatchingFiles.AddItem varFile
; Next varFile
; .cboMatchingFiles.ListIndex = 0
; .lblFilesFound.Caption = CStr(objFileInfo.MatchingFilesFound) _
; & " Matching Files Found:"
End With
; Else
;  
; MsgBox "No files matched the specification: '" & Me.txtFileSpec & "'"
End If
End Sub
The UpdateFileList procedure is available in the frmFindFileDialog module in
ExcelExamples.xls in the ODEToolsV9SamplesOPGSamplesCH06 subfolder on the
Office 2000 Developer CD-ROM.
The class contains several properties used to set the properties of the
FileSearch object. It also exposes the GetFileList method that returns an
array containing all files that match the specified criteria. Public Function GetFileList() As Variant
' This function returns an array of files that match the criteria
' specified by the SearchPath and SearchName properties. If the
' SearchSubDirs property is set to True, the search includes
' subdirectories of SearchPath.
Dim intFoundFiles As Integer
Dim astrFiles() As String
Dim fsoFileSearch As FileSearch
;
 
;Set fsoFileSearch = Application.FileSearch
With fsoFileSearch
;.NewSearch
; .LookIn = p_strPath
; .FileName = p_strName
; .FileType = msoFileTypeAllFiles
; .SearchSubFolders = p_blnSearchSubs
;
;If .Execute(p_intSortBy, p_intSortOrder) > 0 Then
; p_intFoundFiles = .FoundFiles.Count
; ReDim astrFiles(1 To .
FoundFiles.Count)
; For intFoundFiles = 1 To .FoundFiles.Count
; astrFiles(intFoundFiles) = .FoundFiles(intFoundFiles)
; Next intFoundFiles
; GetFileList = astrFiles
; Else
GetFileList = ""
;End If
End With
End Function
The GetFileList procedure is available in the clsGetFileInfo module in
ExcelExamples.xls in the ODEToolsV9SamplesOPGSamplesCH06 subfolder on the
Office 2000 Developer CD-ROM.
__._,_.___
|
[1-8]
|
|