On Dec 6, 3:03 pm, "Peter Duniho" <NpOeStPe...@nn owslpianmk.com>
wrote:
On Thu, 06 Dec 2007 12:36:10 -0800, Tom P. <padilla.he...@ gmail.comwrote:
I am having the following problem: I create a FileSystemWatch er and
wait for events. When the event does happen I refresh a
FileSystemInfo list and set properties accordingly (IsFile, IsDir,
ReadOnly, etc.). The problem I'm having is in identifying when a
FileSystemInfo entry is a FileInfo or a DirectoryInfo type. I get the
rare, and yet oddly common, "setup.inf" file that for some
inexplicable reason passes the standard (FileSystemInfo .Attributes &
FileAttributes. Directory) test but throws an Illegal Cast exception
when cast to a DirectoryInfo object.
How can I reliably determine the specific type from a FileSystemInfo
object?
Well, there's always the Object.GetType( ) method. Depending on what
you're trying to do, often the C# "is" and "as" operators are useful.
"is" allows you to test whether an instance is a specific type, and "as"
is essentially a cast that returns null instead of throwing an exception
when the cast fails.
I don't really get how a file can be rare and common at the same thing.
You're also not clear about where you get the FileSystemInfo instance
from. As far as I know, this isn't something that the FileSystemWatch er
provides you (the event args return paths in strings, not FileSystemInfo
objects). So while there's a way to check the type of the instance, it
would probably make more sense to try to figure out why you get an
apparently incorrect type for the instance in the first place.
Without you having posted any code, it's pretty much impossible for anyone
to assist with that. But until you understand why the Attributes property
doesn't match the type of the instance, I think it's premature to work
around the issue. It may be that things are working as designed, but you
should make sure that's true first. It seems to me that there's a good
chance you're not maintaining your list of FileSystemInfo objects
correctly and it would be a bad idea to obscure that problem with a
workaround.
Pete
Fair enough.
First off the file "setup.inf" is rare in that it is only created as a
result of building an install (*.msi). But, being a developer this is
actually a common occurrence _for me_ so I keep running into this more
than your average user. It's a temporary file but the
FileSystemWatch er will see it before it gets deleted.
You are correct in asserting that FileSystemWatch er only returns a
path. I have to then do a this.Invoke() to call a method on the main
thread that refreshes the watched directory (which is stored in a
member variable so there's no need to pass it). I don't believe the
problem lies in the FileSystemWatch er (since I don't do anything but
call a Refresh() method). The following is the code snippet that I
believe is causing the conflict:
Create a DirectoryInfo for this Path
CurrentDirInfo = new DirectoryInfo(P ath);
//Get an array of all the file system objects in the directory
FileSystemInfoL ist = CurrentDirInfo. GetFileSystemIn fos();
//Loop through each object in the array...
foreach (FileSystemInfo CurrentFileSyst emInfo in FileSystemInfoL ist)
{
FileSystemListV iewItem CurrentListView Item;
//...and determine if it is a Directory (has the
FileAttributes. Directory flag)
if ((CurrentFileSy stemInfo.Attrib utes & FileAttributes. Directory)
== FileAttributes. Directory) //[TAG01]
{
CurrentListView Item = new
FileSystemListV iewItem((Direct oryInfo)Current FileSystemInfo) ; //
[TAG02]
}
else
{
CurrentListView Item = new
FileSystemListV iewItem((FileIn fo)CurrentFileS ystemInfo);
}
this.Items.Add( CurrentListView Item);
}
The if at [TAG01] was copied directly from MSDN.
I've used Console.WriteLi ne to print out the FileAttributes flags and
the file "setup.inf" writes a "-1" rather than "Directory" but the
"if" statement above still evaluates to "true" for the file. When the
code at [TAG01] evaluates "true" then the code at [TAG02] obviously
throws an Illegal Cast exception when it casts the "setup.inf" file to
a DirectoryInfo.
I could get a list of DirectoryInfo objects and then a second list of
FileInfo objects but this seemed more efficient at the time.
It looks as if the "is" keyword is what I need here. A simple test of
whether the particular item is a DirectoryInfo object or a FileInfo
object. Then I don't have to rely on the FileAttributes flags at all.
Thanks,
Tom Padilla
