I have a program where I am using windows form, in that form I use openFileDialog where I open a file in some directory. Then I use in a different function a StreamReader and I have a 2nd file in my big/debug directory which I want the streamReader to open. But for some reason after I open the 1st file with the openFileDialog the StreamReader looks for the 2nd file in that directory instead in bin/debug as usual.
Does anyone know why he does that and how can I solve it?
Thanks in advance,
Greg
The OpenFileDialog has that behavior; it alters the current directory for the application. To prevent this from happening, you can use the RestoreDirectory property of the OpenFileDialog.
When you change directory in an open file dialog, this also causes your application's working directory to change. So if you are trying to use relative paths, it will look in the wrong place.
The solution is RestoreDirectory.
If you don't specify a complete file path but only a file name, that means that the file is in the current directory. When you use the OpenFileDialog, it changes the current directory.
If you want to access a file somewhere regardless of what the current directory is set to, you have to specify a complete path for it. You can use Application.StartupPath to get the path to the folder where your program is.
Related
when the SaveFileDialog opens for the first time it has an initial directory. I would like to get that path.
And also if I go into C:\Temp and save a file. Next time I open the SaveFileDialog the program will remember this. I would like to have this path also. Or do I have to save this manual in my program?
Best regards
R
You have to set FileDialog.RestoreDirectory to true.
I'm creating a program that controls if words in a textbox are present in a text file.
The question is: Is there a way to find the path of that file without depending on the computer you're on?
If you don't use an absolute value for the path - it'll always try to resolve it relative to where your application is.
So if you put the file in the same folder as your application, it'll find it.
Otherwise, if you want your user to locate the file for you, you could use an OpenFileDialogExample here
Another option is to use one of the 'known' paths (such as My Documents). You can do this using Environment.GetFolder
But all of these depend on what you're trying to do exactly.
You can use relative paths. For example, if your path is "file.txt" and save the file, it will be saved next to your exe. Same thing for opening.
I have a openfiledialog in my application. I do not set the initial directory and user can navigate to open file and import it to the application (for example imports excel file from C:\ Test location). Next time, when user wants to open another file, system (by default, since initial directory is not set) remember the previous location and openfiledialog opens in that directory (C:\ Test). Is there anyway to retrieve the path that openfiledialog opens? I am sorry if I couldn't explain my problem well and thanks for the help.
Registry is hard to handle, I would suggest that you use Application Properties instead.
I am using WritePrivateProfileString in c# (through DllImport) to store paths taken from textboxes on the interface. And the .ini file name is hardcoded in my application
string ini_file = ".\\config.ini";
However, when the file writing happens, the configuration file is written to the first path taken from the interface instead of writing it to the exe directory. Which is quite odd.
Debugging shows that the values are sent correctly to the WritePrivateProfileString but it still is written to the wrong location. Anyone knows why is that happenening?
I'd guess that something is changing the working directory of your process, most likely your code in the process. Note that the documentation has this to say:
If the lpFileName parameter does not contain a full path and file name for the file, WritePrivateProfileString searches the Windows directory for the file. If the file does not exist, this function creates the file in the Windows directory.
Now my guess is that this applies if you supply just a file name. Because your file name starts with . I believe that will force the function to start from the current working directory.
Having said all of that, and no matter what the cause of the problem is, you should use a fully-qualified path in order to make sure the file is written where you want it to be written. Whenever you want the file to go in a specific directory, it's always easiest to force that by using fully-qualified paths.
You can find the path to your executable using Application.ExecutablePath and then remove the file name part.
Another point to make is that the same directory as the executable may be a bad choice. If your program is installed under the Program Files directory then the directory which contains the executable will not be generally writeable. I think you should consider using a directory under in the user profile. Look for one of the Environment.SpecialFolder values.
Further to David Heffernan's answer - you can use
Path.GetDirectoryName(Application.ExecutablePath);
to safely get just the running application's folder part.
If you're in a dll rather than an executable, you can use
Path.GetDirectoryName(Assembly.GetAssembly(typeof(MyClass)).CodeBase);
Both require System.IO, and were originally posted here. Second example also requires System.Reflection).
Application data files are supposed to be written to the LocalApplicationData special folder.
string path = System.Environment.GetFolderPath(System.Environment.SpecialFolder.LocalApplicationData);
You typically will not have permissions to write into the Program Files folder etc.
So I'm using a SaveFileDialog to save a file to a location the user selects. After the saving has occurred, the user is able to do what they want with the file and folder they saved to.
However, the user cannot delete or modify the folder...it's being held in memory by the application so when another SaveFileDialog is opened, it can point to that same directory.
Our application is fairly complex and I don't want this sort of feature enabled. Is there a way to turn it off?
Thank you in advance.
Short from mis-behaving shell extensions, this is normal. SFD will change the current working directory of your program to the directory that contains the file selected by the user. And that puts a lock on the directory.
You avoid this by setting the RestoreDirectory property to True.
Make sure you're disposing the stream or whatever resource you're using to actually write the file. This resource is most likely staying open locking the folder and file. Read about the using() syntax here http://msdn.microsoft.com/en-us/library/yh598w02(VS.80).aspx.