OpenFileDialog and passing a relative directory automaticly to it

[Peted]

Hi

i have a circumstance where a user unzips a file, with a certain layer
of directories to get to a textfile.

So in any directory on the HDD they may end up with something like
dir1/dir2/dir3/dir4/dir5/file.txt

in most cases i can be sure the zip fie will extract as shown, but in
reality the only thing i could be certain of is the number of
directory layers and the specific names "dir5/file.txt"

so using OpenFileDialog, i want to have it auto open for the user to
the directory "dir5" so that they can click and select file.txt
without having to traverse the directories manually.

Becasue i know the numeber of directories layers will be the same, if
the directory names are not the same, how can i send releative path
information to OpenFileDialog so that it opens in correctly in dir5
for the user to select file.txt.

I must do this using relative paths, because they may extract the zip
file anyware.
any advice or help appreciated. thanks

Peter

[Peted]

Sorry i should have mentioned that i can determine the directory the
zip file is in when extracted, so i need to work out how to send
relative path information from that known directory to OpenFileDialog

Peter

>Hi

i have a circumstance where a user unzips a file, with a certain layer
of directories to get to a textfile.

So in any directory on the HDD they may end up with something like
dir1/dir2/dir3/dir4/dir5/file.txt

in most cases i can be sure the zip fie will extract as shown, but in
reality the only thing i could be certain of is the number of
directory layers and the specific names "dir5/file.txt"

so using OpenFileDialog, i want to have it auto open for the user to
the directory "dir5" so that they can click and select file.txt
without having to traverse the directories manually.

Becasue i know the numeber of directories layers will be the same, if
the directory names are not the same, how can i send releative path
information to OpenFileDialog so that it opens in correctly in dir5
for the user to select file.txt.

I must do this using relative paths, because they may extract the zip
file anyware.
any advice or help appreciated. thanks

Peter

[Peter Duniho]

On Mon, 03 Nov 2008 23:38:29 -0800, <Petedwrote:

Hi

i have a circumstance where a user unzips a file, with a certain layer
of directories to get to a textfile.

So in any directory on the HDD they may end up with something like
dir1/dir2/dir3/dir4/dir5/file.txt

in most cases i can be sure the zip fie will extract as shown, but in
reality the only thing i could be certain of is the number of
directory layers and the specific names "dir5/file.txt"

I'm not sure I understand. Are you saying that you don't know the names
of the first four directories? Just the fifth one?

so using OpenFileDialog, i want to have it auto open for the user to
the directory "dir5" so that they can click and select file.txt
without having to traverse the directories manually.

You can set the InitialDirector y property of the OpenFileDialog before you
show it. But you _have_ to know the full path to the file you're
interested in.

Becasue i know the numeber of directories layers will be the same, if
the directory names are not the same, how can i send releative path
information to OpenFileDialog so that it opens in correctly in dir5
for the user to select file.txt.

Knowing the depth of the path in number of directories is helpful only if
you are guaranteed that at each level, there is always only one directory
to pick from. Otherwise, you have no way to know which directory to pick
at each level.

If you know the actual filename, _and_ you know that filename is unique
within the subdirectories that have been extracted, then you could do a
search of that subtree of the file system to find the file. But, if you
know the actual filename, it begs the question as to why you'd need to
present the user with the file dialog in the first place.

I must do this using relative paths, because they may extract the zip
file anyware.

I'm not sure what you mean here. Just because the files can be extracted
anywhere, that doesn't preclude using absolute paths. At some point, you
have to know _where_ the files were extracted, and at that point, you can
then construct a full absolute path representing that location.

If all you mean is that the operations to locate the file have to be
relative to some known location, then that makes sense, but that's not
really a constraint to use only relative paths. It just means that
whatever inspection of the file structure you have to do is itself
relative. The paths involved may well be absolute (and frankly, probably
should be...otherwise, you're relying on the current working directory for
your process not changing, which might be a fine assumption now but can be
easily broken in the future and is a horrible dependency to put into the
code).

Pete