I generally have multiple copies of files in different directories or different disks, that I routinely compare in order to determine what changes have occurred.
In such cases, the file names of the files being compared are the same, only the path or location is different.
When I use wincmp from the command line, I don't want to enter the file name twice, so I usually just enter the path (including file name) for the first file, and just the path to the second file (without the file name).
But many times when I do this, I get the dialog which says "DESTINATION FILE NOT FOUND!", and I have to enter the path and name of the second file.
For example, lets suppose that the current directory on the E: drive is "data", and the current directory on the G: drive is "files", and e:\data and g:\files contains the files I am working with.
If I set my current directory to e:\data, then when I enter the following command, then I get the "DESTINATION FILE NOT FOUND!" dialog:
wincmp3 w9.txt g:
Notice that for the second file path, I only entered the drive letter g:, and no path.
To get around this, I can enter this command, and it works:
wincmp3 w9.txt g:.
Notice that I entered a "." after g: . The "." directory of course means "the current directory". But so does leaving it off.
If w9.txt exists in the root of the g: drive, then I do not get this dialog, or if I enter this command, it works as well:
wincmp3 w9.txt g:w9.txt
When I enter g:w9.txt, in this case I am not entering the path, only the file name, yet it still seems to find the file. The behavior is not entirely consistent.
I should not have to do this, and I have difficulty remembering to do this, especially since other programs do not require this.
As a reminder, if I enter just a drive letter, such as G:, this does not mean the root of the g: drive. It means the current directory of the g: drive. The root of g: would be indicated by g:\.
Can you please correct this, in order to conform to the concept of "current directory" as expected?
Better command line support
Thanks for your quick response.
MSDN says this:
"Processes under Windows NT maintain only one current directory. Under MS-DOS or OS/2, a process will maintain a current directory for each drive."
"CMD.EXE maintains a private current directory for each drive it has touched and uses environment variables to associate a current directory with each drive."
Open a command shell, and go to different drives, and on each drive, CD to some specific folder. Then go back to each drive and notice that the per drive default directory is still retained.
But this is probably the command shell that is implementing this concept of a current directory for every drive.
Despite this, in my own programs, I have found that if I access a file using a file path such as "g:w9.txt", or some other path that is relative to the current directory, such as "g:.\w9.txt", and if I pass that path to _fullpath, it will locate the file given the current directory for the drive, and it will return the fully qualified path.
At least when I run the program from a command shell this works, and so I suppose that this works because MSDN said that CMD.EXE maintains a private current directory for each drive.
And since I am running wincmp3 from a command line in a command shell, then this should be available to your program as well.
So what I would suggest, is that first you try to see if the destination path as entered exists as is. If not, then if the path ends in : or \, then add the name of the source file to the end of the destination specified, and try to open it. Else add a \ and then the name of the source file, and try to open than file:
g: add w9.txt - try g:w9.txt
g:. add \ then add w9.txt - try g:.\w9.txt
g:\ add w9.txt - try g:\w9.txt
g:temp add \ then add w9.txt - try g:temp\w9.txt
g:temp\ add w9.txt - try g:temp\w9.txt
If wincmp3 is launched from Windows Explorer, then the current directory thing probably won't work and no file will be found, and the dialog will display, which is fine.
It is when I run from a command shell that it should work.
-Dan-
MSDN says this:
"Processes under Windows NT maintain only one current directory. Under MS-DOS or OS/2, a process will maintain a current directory for each drive."
"CMD.EXE maintains a private current directory for each drive it has touched and uses environment variables to associate a current directory with each drive."
Open a command shell, and go to different drives, and on each drive, CD to some specific folder. Then go back to each drive and notice that the per drive default directory is still retained.
But this is probably the command shell that is implementing this concept of a current directory for every drive.
Despite this, in my own programs, I have found that if I access a file using a file path such as "g:w9.txt", or some other path that is relative to the current directory, such as "g:.\w9.txt", and if I pass that path to _fullpath, it will locate the file given the current directory for the drive, and it will return the fully qualified path.
At least when I run the program from a command shell this works, and so I suppose that this works because MSDN said that CMD.EXE maintains a private current directory for each drive.
And since I am running wincmp3 from a command line in a command shell, then this should be available to your program as well.
So what I would suggest, is that first you try to see if the destination path as entered exists as is. If not, then if the path ends in : or \, then add the name of the source file to the end of the destination specified, and try to open it. Else add a \ and then the name of the source file, and try to open than file:
g: add w9.txt - try g:w9.txt
g:. add \ then add w9.txt - try g:.\w9.txt
g:\ add w9.txt - try g:\w9.txt
g:temp add \ then add w9.txt - try g:temp\w9.txt
g:temp\ add w9.txt - try g:temp\w9.txt
If wincmp3 is launched from Windows Explorer, then the current directory thing probably won't work and no file will be found, and the dialog will display, which is fine.
It is when I run from a command shell that it should work.
-Dan-