FileSystemWatcher Fun
I wrote an application awhile back (hopefully to be online for download soon) that caused me to increase my knowledge of the FileSystemWatcher (FSW) class. Wow! This thing has got some power.
First, a quick explanation of what it can do for you. Think of it as a guard dog. If something moves, it barks. If something, new drops out of nowhere it barks. If something disappears, it doesn't care. The FSW can be setup to watch ANYTHING. Directories, files, even hidden objects are monitored by this class. How would you then use this? In my case I was updating and creating files that needed to be reflected to the user via a Windows desktop application.
Second, what things will make using FSW make you scream. Believe me, this is no joke. A great page with tips that illustrate what I am talking about is on Ashutosh Nilkanth's .NET Blog. Some of the more irritating issue revolve around multiple event execution and the built-in cache size.
The one I want to concentrate on now is the cache. If you are planning on taking action based on the event being executed, you will quickly find that putting code into the event handler function will make profanity almost second nature. As it turns out, the FSW object caches the request and then attempts to execute all code in the event. Sounds good, doesn't it? Well, additionally it will NO LONGER RAISE AN EVENT FOR OTHER FILES until the current event process finishes. !!!
I did end up determining a workaround for this that, while convaluted, does provide the end results I needed. The answer? The Queue object and a Timer object. In my event handler for the FSW I add the filename to the Queue object and enable the timer. The time is set to the smallest interval and processes the files in the Queue. That's it!
While adding a Queue and Timer object causes an increase in memory for the application, it did not significantly impact my application and so I was happy with this implementation.
Other links:
C# Corner
Know Dot Net
Code Guru
The Code Project
First, a quick explanation of what it can do for you. Think of it as a guard dog. If something moves, it barks. If something, new drops out of nowhere it barks. If something disappears, it doesn't care. The FSW can be setup to watch ANYTHING. Directories, files, even hidden objects are monitored by this class. How would you then use this? In my case I was updating and creating files that needed to be reflected to the user via a Windows desktop application.
Second, what things will make using FSW make you scream. Believe me, this is no joke. A great page with tips that illustrate what I am talking about is on Ashutosh Nilkanth's .NET Blog. Some of the more irritating issue revolve around multiple event execution and the built-in cache size.
The one I want to concentrate on now is the cache. If you are planning on taking action based on the event being executed, you will quickly find that putting code into the event handler function will make profanity almost second nature. As it turns out, the FSW object caches the request and then attempts to execute all code in the event. Sounds good, doesn't it? Well, additionally it will NO LONGER RAISE AN EVENT FOR OTHER FILES until the current event process finishes. !!!
I did end up determining a workaround for this that, while convaluted, does provide the end results I needed. The answer? The Queue object and a Timer object. In my event handler for the FSW I add the filename to the Queue object and enable the timer. The time is set to the smallest interval and processes the files in the Queue. That's it!
While adding a Queue and Timer object causes an increase in memory for the application, it did not significantly impact my application and so I was happy with this implementation.
Other links:
C# Corner
Know Dot Net
Code Guru
The Code Project
posted by WWWGeek at
7/29/2005 09:05:00 AM
