Hi Pete,
see the difference:
First you did:
Code:
SET DEFAULT TO C:\tempVFP\12-26_reStart
Now as it works you did:
Code:
SET DEFAULT TO C:\temp-CallDetail\12-29
Maybe you also copied the xml file around to the other directory, but anyway, if vfp does not find the file it's surely no vfp bug, that would be known. If the file exists there vfp either has no access to the whole directory or one of it's parent dirs or the file is hidden or in a hidden dir, there is no other way.
Another issue you could have had, is that you set up Windows Explorer to suppress file extensions of known extensions and then added a txt or xml, so the real filename may have been C0_5528.xml.txt or C0_5528.txt.xml during your experiments.
I turn that option off as the default, because as a programmer it's important you know the file names as they are for real, for a user it may be sufficient to see the main part of the filename, the stem, together with the icon associated with eg the ms word doc ending or something else, but for the programmer this is of no value.
I don't think it was an access right issue, then you would have got another error.
Did you really SET DEFAULT TO ... the way you posted or did you simplify the code where you predetermine the path like C:\temp-CallDetail\12-29 with eg a date, 12-29 looks like a date part. If you do that wrongly CD will not put you in the right path you thought of.
Anyway I'd advice you do the following steps regarding paths and files:
First of all don't hardcode paths into code, make them part of a configuration, eg a free dbf. You may want to change you directories organisation at some point and then you're either stuck with such code and forced to leave the files where they are or you need to find all paths in the code an change them accordingly.
Make some paths.dbf with the fields cPathalias and cPath. The pathalias could be a short description of the path you take to lookup the real path, in your example that pathalias may be XMLFILES. cPath could be a Memo and cPathalias a C(20) field.
You will have paths that are specific to one app or to all apps and so you'd ideally have one local paths.dbf, local to your app, and some public paths.dbf somewhere in a network share. Then put the path to the public paths dbf into the local paths dbf and you only need to know that path. And that path could be Justpath(Sys(16,0)), which is "here", the path where the main.prg is located.
If you have that you'd do something like this:
Code:
Local lcXMLPath
lcXMLPath = GetPath("XMLFILES")
Local lcXMLFile, lcXML
lcXMLFile = AddBS(lcXMLPath)+"C0_5528.xml"
lcXML = FileToStr(lcXMLFile)
...
Function GetPath()
Lparameters tcPathalias, tlGlobal
Local lcPathsAlias
lcPathsAlias = iif(tlGlobal,"global","local")+"paths"
Local lcPath
If !Used(lcPathsAlias)
If tlGlobal
* get global path from local paths (tlGlobal = .F. explicitly)
Use (GetPath("GLOBALPATHS",.F.) In 0 Alias (lcPathsAlias)
Else
Use (Justpath(Sys(16,0))+"paths.dbf") In 0 alias (lcPathsAlias)
Endif
Endif
Select cPath From (lcPathsAlias);
Where cPathalias=tcPathalias;
Into Cursor curPath
If _tally = 1
lcPath = curPath.cPath
Else
Messagebox("Path "+tcPathalias+" not found! Please add it to the appropriate paths.dbf")
Suspend
Endif
Return lcPath
Endfunction
You may implement GetPath() differently, the point is, that it will be the only function needing a "static" path, and even that is determined dynamically with SYS(16,0). You need at minimum the two paths dbfs and the path to the GLOBALPATHS within the local paths.dbf for this function to work properly.
You then get local paths by GetPath(cPathalias) and global ones by GetPath(cPathalias,.T.).
As a side effect you will never need to CD or SET DEFAULT TO some path, as you always can put together a full path easily. But even if you do, then CD (GetPath(cPathalias)) will work anyway. All commands having paths as their options should be used with a name expression, eg CD ("some path") or also CD (FunctionResultingInSomePath()) Otherwise CD some path will look for "some" and error on "path" as that is parsed as an additional and invalid option, not as part of the path. CD lcSomevariablename will look for a path called lcSomevariablename and not look for the path stored in lcSomevariablename, therefore you also need CD (lcSomevariablename) in that case.
The rule regarding paths and filenames and name expressions all in all is very easy: Always use name expressions (...) when you use a command, never make use of the option to directly write paths. So een use CD ("c:\temp") instead of CD c:\temp, and you'll never need to think about when you need to change because of spaces within a path.
A Function like FileToStr() will not take a directly written path anyway, but evaluate the value of it's path parameter, therefor you don't need name expressions there, but can use them anyway.
And another recommendation: ADIR() will always look on disk for the file, while most functions will also search along paths set by SET PATH. So you can check if VFP finds a sepcific file by IF ADIR(aDummy,<<specific file name>>)=1. If ADIR gives 1 then it there for sure. Otherwise i may be existing but hidden or vfp has no access to some dir on the way to the file.
Bye, Olaf.
