How to constantly check something without using a Timer

[TomLasky]

Hi everyone, I'm an old school vb6 user trying to transition to VB.NET.

Can anyone suggest a better approach to constantly checking something without using a timer?

I'm trying to constantly check a folder of text files to get the date modified of each file. I have no problems creating the filesystem object to extract the file info and dates. Currently using a timer I know is a poor approach to this but need some insight into a better way of constantly looping so the system resources aren't hogged.

Any help would be greatly appreciated.

[joedeene]

I would use a timer? If you want to constantly refresh a directory's files and information for each file I'd use a timer but set its refresh rate/interval to like 1000 milliseconds. I know it would be better then using a Do While Loop statement, because it would freeze the program up.

joedeene

[lotus18]

Try FileSystemWatch er component : )


Rey Sean

[balabaster]

Try FileSystemWatch er component

Definitely the best approach.

There are some caveats to watch out for though - when you do a file rename or a save it'll cause a bunch of extraneous events to occur, so what you really have to do is wait for the event and then attempt to get a file lock on that file. Once the file lock occurs, the file has finished saving/writing and then you can go on to trigger what you need to.

If you go off the regular event, then you can run into concurrency issues.

The changed event can run many times on a file save. The created event however, is only raised once.

[boyank]

It's also worth noting that the FileSystemWatch er implementation does not work well for network directories (access through UNC paths or as mapped drive).

[TomLasky]

Everyone, Thank you very much. I truly appreciate your replies. Your recommendations worked out for me!

[tlhintoq]

It's also worth noting that the FileSystemWatch er implementation does not work well for network directories (access through UNC paths or as mapped drive).

I'm curious about this comment. You say it doesn't work well over a mapped drive or UNC path. I assume you have had bad experiences with this?

The reason I ask is because a couple of my programs use this extensively and I haven't seen any problems in the last year.

9 computers; each dumping 1800 jpg's per 8-hour day into directories on a server.

13 other computers reacting to those new files based on FileSystemWatch er, to either display or process the files in a given way.

I haven't seen an issue so far. What kind of issues have you run in to so I can try to head off problems?

Regards,
tlhIn'toQ

[tlhintoq]

Definitely the best approach.

There are some caveats to watch out for though - when you do a file rename or a save it'll cause a bunch of extraneous events to occur, so what you really have to do is wait for the event and then attempt to get a file lock on that file. Once the file lock occurs, the file has finished saving/writing and then you can go on to trigger what you need to.

If you go off the regular event, then you can run into concurrency issues.

The changed event can run many times on a file save. The created event however, is only raised once.

What do you think of this approach? Maybe you have a better scheme that what I do now.

I usually react to the event of a new file by adding it to a list of files to be processed. Then take it off the list after processing is successful. That way I can deal with a list of 2000 path strings, instead of 2000 triggered events.

[balabaster]

What do you think of this approach? Maybe you have a better scheme that what I do now.

I usually react to the event of a new file by adding it to a list of files to be processed. Then take it off the list after processing is successful. That way I can deal with a list of 2000 path strings, instead of 2000 triggered events.

Sounds good. I usually try and queue up the file into a dictionary so I don't get duplicates. I then check for an exclusive lock when I come to process the file to check that its finished processing.

[tlhintoq]

A dictionary... <light bulb>... I hadn't thought of that. Just never made the connection. I always just used a List<string> and did a manual search of the list before adding to avoid duplicates. I never put 1 and 1 together to get 10, that a dictionary inherently doesn't allow duplicates. Thanks!