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.
Related
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.
This is what I'm trying to do :
Download a file (txt, doc, xls, whatever) from a server
Open the file with the appropriate application using System.Diagnostics.Process.Start(path to file)
Monitor for file changes using a FileSystemWatcher.
Each time the file is changed, upload the file back to the server
Continue monitoring until the user has finished editing the file
Delete the local copy of the file
Exit the application
I'm stuck at step 5. How can I know whether a user has finished working on a file ?
I cannot rely on the file being locked (notepad doesn't lock txt files for example).
I cannot rely on a process having exited or not (an example is Notepad++ for txt files : the file could be open in a tab. When you close the tab, you've finished editing the file, but the process is still running)
Any idea/points on how to do that in C# ?
You've excluded the two ways you could go about detecting the file being in use: file locking, and the process you start exiting.
The only alternative I an think of is to display a dialog to ask the user when they've finished editing.
Edit: For what it's worth - FileZilla has this type of behaviour. You can choose to edit a file on the remote server, it downloads the file, launches the default editor, and (in the background) shows a "If you've finished editing - Click OK" button.
This gives me the opportunity to cancel an edit, if I've mucked up the file and saved it.
This is really hard to do - we've tried various things but never found anything that was foolproof. If you know the program you have launched then, in theory, you can find the file handles it uses and see when it stops using the one you're interested in.....but if you rely on Windows to resolve the default application to launch even this becomes tricky.
We copy editable files into a temp folder named with the date and rely on users uploading them back when they have finished their edit session. We then clean up previous days folders on application startup.
You could check the date of last change of the file. This date gets set when you save changes to the file. Mind though that this field is not very reliable since one can set it to any value (with appropriate tools).
how could i implement autosave in C#? i felt that saving to the currently open file is a simple but i may not want to overwrite my previous file (or should i just do that? i think google docs saves/overwrite the document tho they have version control?). i thought of saving to another file, but where do i save to?
also i guess i will have to know if there's any autosave files to retrieve and after a explicit save, i should remove the autosave file associated with the current document
Current versions of Microsoft Office (for example) save to a "shadow copy" of the working file. Depending on how you want it to work, you can have writes applied to the shadow copy every n seconds or when certain types of actions are taken.
When the program is shut down, the original is deleted and the shadow copy is renamed to the original. There are lots of options and strategies within this technique that can be applied depending on your particular situation and requirements.
You should create a Temporary File for the autosave. If the User saves, you can delete the file, and if your app crashes and is restarted it can load the last autosaved state from the file.
say my application is installed in C:\programfiles\xyz\ I've some setting & other data files (*.dat files) in this directory too.
My application uses OpenFileDialog to open an image. Problem is that when ever user browses to some directory (say MyPictures) for an image. The current working directory of the application becomes that directory (MyPictures in this case).
After user inputs the image. I do some processing over it and save some values to imagedata.dat which will be located in the path where original application is installed.(C:\programfiles\xyz here )
In my code I'm just using FileStream("imagedata.dat",...,...) without any path prefix before the filename. Problem here is that application is crashing because it is searching for imagedata.dat in 'MyPictures\imagedata.dat'.
How can I avoid this?
You should be using absolute path names when saving data to files. The current working directory is controlled by the user, not by you (for example, if they launch your process from a shortcut then the working directory could've been changed before your process even starts up).
Also, you should never save anything under C:\Program Files during normal use. Doing this means your program needs to be running as an administrator, and unless you're doing administrator-y things then you should be able to run it as a regular user.
The correct thing to do in your case is to use the Environment.GetFolderPath() function to get the location of the ApplicationData folder and save your data under there. Just choose a sub-directory based on your application's name.
You could save it to GetCurrentDirectory then restore with SetCurrentDirectory. However, I agree wih codeka that using the appropriate GetFolderPath (probably ApplicationData, CommonApplicationData or LocalApplicationData) is a better solution.
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.