I have two applications having reference to same xml file. One writes to the file, other monitors changes to the file.
In Application 1, I have used FileSystemWatcher to monitor changes, applied filter as LastWrite and watching for change event only. It runs continously in background
Application 2 reads a specific node in the file at startup and updates the node on users direction. Its a simple windows form, that reads a value from file when executed, and has the facility to change that value
Strange thing I came across when running both the applications, is that when application 2 starts up, file change event is raised in application 1 (Note: Application 1 continously watches the file)
I want to get rid of the change event raising in application 1 when application 2 starts up.
Is the filter incorrect or the Change event behaving nasty?
This behavior is documented:
The Changed event is raised when changes are made to the size, system
attributes, last write time, last access time, or security permissions
of a file or directory in the directory being monitored.
If Application 2 opens the file and the OS keeps track of last access times, a Changed event will be raised. Since there's no facility to filter only those events that actually write data to the file, you will have to determine what happened by keeping state on Application 1.
For example, now that you know what's going on you can keep a cache of the last write time and decide to ignore the event if that hasn't changed.
Related
I want to crete a program that does the following;
Give the user 2 input fields for Directory1 and Directory2 on starting the application.
When a file is added (not updated) to Directory1 -> move file to Directory2
This program needs to be running at all times and preferably move the newly added files within 5 seconds.
I'm on windows and use C#.
I'm not sure what template to use, a windows service or a windows form application?
Also example code or references are appreciated, thank you.
This program needs to be running at all times
This seems to point into the direction of a service.
Give the user 2 input fields for Directory1 and Directory2 on starting the application.
This is a bit of a contradiction to the upper requirement. Either it runs all the time or it has to be explicitely started. Either way, even if you run it as a service, you will need an addtional application, that handels the GUI part, because services don't have a GUI.
Once you've figured that out, you can have a simple FileSystemWatcher watching your directory. It will notify you on all sorts of events that happen in this directory (file create, delete, change, ...) Just check for the desired event and act accordingly.
I implemented FileSystemWatcher in a windows forms application. Changed event is working when I open a file (say pdf-1) for the first time. But when I open the same file for the second time within short span of time, changed event is not firing. But it is firing when I open another file (say pdf-2). Again the changed event is firing for the first file (pdf-1) only if I open it after some time (say 1 or 2 hours).
I set the InternalBufferSize to 16KB and the NotifyFilters used are LastAccess, LastWrite, FileName and DirectoryName.
I am unable to find out the issue. Can anyone help me out?
I have seen similar results with FileSystemWatcher for RAID controller disks, SCSI disks and regular IDE disks with write cache enabled.
I also experienced a lot of other errors that may have been caused by thread synchronization problems. Here is another description of this problem.
My WPF app uses Log4Net to record messages to the event viewer. This is working great on most machines. However, there are two machines in my office where there are problems. One is a physical Windows 7 machine with 2 GB of ram, the other is a virtual machine running XP, which also has 2 GB of ram.
The problem is that even though the users are logged in using accounts with administrator rights, the system won't let them create the custom event log that I set up for my application. This is causing my program to die.
I can add error handling on all of the Log calls, but my feeling on this is I shouldn't. The messages are being logged in the catch handler for another error that already occurred. Just what am I going to do with the error information if it can't be logged?
In any event, I tried to create the custom event log on the XP virtual machine yesterday and it still wasn't created. What exactly do I need to do to get the custom event log created on these two machines?
Tony
It turns out that the problem wasn't in the logging code at all. My program uses WPF for the GUI. It's start-up sequence does the minimum amount of work on the UI Thread so it can display the UI as soon as possible.
The rest of the initialization is done on a background thread. I knew that an error was occurring, but I couldn't find the custom error log in the list of logs in the Event Viewer. It turns out that my code didn't find some data in the database that it needs and was trying to report the error. This is a 2 step process which involves first recording the error to the log and then displaying a custom MessageBox dialog. I was getting a XamlParseException when the program was trying to display this dialog.
To make a long story short, the problem that was crashing the program was the XamlParseException. This was thrown because I was calling the custom MessageBox's Show method on the background thread, not on the UI thread. Because I couldn't find the custom event source in the event viewer, I couldn't find the error, so I assumed that the error was a permisions issue.
By the way, I did try to create the event log manually at one point, and yesterday I checked the registry and did find the entry for the custom event source.
There is one other machine here that is having the same problem. I'm sure it's the same exact issue. I'm adding logic to the error handling to make sure that the custom MessageBox is always called on the UI Thread so the program won't bomb like that if the same issue recurs.
We would need to see how you tried creating the event log on the XP machine...
Generally, you need to read this: http://msdn.microsoft.com/en-us/library/49dwckkz(v=vs.80).aspx
Particularly the note discussing when to create your custom event log:
"In general, create the new event source during the installation of your application. This allows time for the operating system to refresh its list of registered event sources and their configuration. If the operating system has not refreshed its list of event sources and you attempt to write an event with the new source, the write operation will fail. If creating the source during installation is not an option, then try to create the source well ahead of the first write operation, perhaps during your application initialization. If you choose this approach, be sure your initialization code is running with administrator rights on the computer. These rights are required for creating new event sources."
Try creating the custom log in advance of the first logging event to use it.
I'm using the FileSystemWatcher to monitor a certain directory, and I need to raise one event when someone saves edits to a file, and another when they create or move a file.
Monitoring moved files works fine using a combination of the Deleted and Created events. And when someone saves edits to a file the Changed event does indeed get raised. However, when they move a file the Changed event gets raised too, and that interferes with the handling I've got for the Created and Deleted events.
So basically, I want to raise the Changed event only when the user saves edits to a file, while not when the user moves or creates a file. I tried using the ChangeType property to check if it was in fact a Changed event or a Created event, but to my surprise, the ChangeType Changed was raised for the Change event even when moving or creating a file, not the ChangeType Created (which supposedly should be one of the types).
So I don't know how to check that the Change event is actually triggered by a file edit, rather than file creation or move...
Any ideas?
This is normal behavior when you apply some of NotificationFilter such as NotifyFilter. Attributes and NotifyFilter.LastAccess, it will even notify Changed twice if both filters was applied when file move "Deleted - Created - Changed - Changed", So:
Simply don't add not relevant notify filters; If you just remove
NotifyFilter. Attributes and NotifyFilter.LastAccess
you will not receive Changed event when move file, only Deleted then Created.
If you are wishes to stick with the notify filters that you are already using, there is other hint here to allow you to generate a dirty solution, it is the fact that when the file moved, the sequence of notification will be Deleted, Created then Changed, they will be always in this order..
I have a settings save method I call, but I tried unload, and lost focus the application will close out and not save before ever getting to either of those methods. When should I save application settings to keep this from happening?
Should I use a timer and save every 30 seconds, or what?
How often you save depends on your app. However, the key timings are:
Launching
Activated
Deactivated
Closing
Launching is called when the app is first launched from the main screen and Closing is called when the user presses the back key to exit your app. Naturally, you'll most likely want to save permanent data in the Closing event.
Activated is called when the user has closed your app via the Windows button and has gone back into it by pressing the back button. This doesn't get called if the user launches the app for the first time.
Likewise, the Deactivated event is called when the user presses the Windows button. Depending on your app, you'll want to save transient data at this point so that when it's restored, you can give the illusion that your app wasn't closed at all. (Otherwise, for example, all textboxes will become empty even if the user entered data before pressing the Windows button).
Those are the main events, so you can design your app around that. One thing to remember is that if your save files are going to be big, and they take longer than 10 seconds to save after the closing event is called, your app will be terminated immediately, possible corrupting the save file. Therefore, for large saves files, you should plan ahead by saving incrementally (for example, after the user has made a change that should remain permanent).
There's no one size fits all solution to this as saving timings are highly dependant on the type of app being developed. Have a read of the Execution Model MSDN Page as it goes into more detail and provides code examples.
Here is a sample from MSDN on how to implement settings page for Windows Phone.
http://msdn.microsoft.com/en-us/library/ff769510(v=vs.92).aspx