OpenFolder Dialog

[MrKrich]

Is there is something like OpenFile Dialog but open folder
instead?

[Anthony Fine]

I am running VS 2003, and there is a FolderBrowserDialog control. I looked
on another machine running VS 2002, and the control did not seem to be
available. However, you could achieve this using API calls as well.

Anthony

"MrKrich" <an*******@discussions.microsoft.com> wrote in message
news:01****************************@phx.gbl...

Is there is something like OpenFile Dialog but open folder
instead?

[Herfried K. Wagner [MVP]]

* "MrKrich" <an*******@discussions.microsoft.com> scripsit:

Is there is something like OpenFile Dialog but open folder
instead?

NET 1.1:

'System.Windows.Forms.FolderBrowserDialog'

Note that there is a bug in Fx 1.1 that causes a really bad error when
using a path which is longer than ~128 characters. This occurs on unicode
systems only. Use the PInvoke solutions mentioned below instead.

The property for hiding the button that allows the user to create a new
folder doesn't work on Windows 2000.

..NET 1.0:

<http://www.codeproject.com/cs/miscctrl/folderbrowser.asp>
<http://support.microsoft.com/?kbid=306285>
<http://www.gotdotnet.com/team/vb/FolderBrowser.exe>
<http://groups.google.com/groups?selm=q0JKzDbmCHA.2144%40cpmsftngxa09>

--
Herfried K. Wagner [MVP]
<http://www.mvps.org/dotnet>

[Cor]

Hi Herfried,

I was waiting for it Herfried.

:-))

A real question, how many people are using paths longer than 128characters,
in a commandline you even cannot type it as far as I know.

So it is an error, however what me triggers are the words "real bad error"

Cor

[Simon Verona]

A path name of more than 128 characters is long, but not extreme by any
means...

It's nice to know of the bug, it's the sort of thing that you would never
have a problem with in development or testing, but you could guarantee that
the first real user would have a real long path name.... Murphys Law and
all that!

Regards
Simon
"Cor" <no*@non.com> wrote in message
news:Ob*************@tk2msftngp13.phx.gbl...

Hi Herfried,

I was waiting for it Herfried.

:-))

A real question, how many people are using paths longer than 128characters, in a commandline you even cannot type it as far as I know.

So it is an error, however what me triggers are the words "real bad error"

Cor

[Cor]

Hi Simon,

The change that it is when there is an error gives the real file name is
low, so it means that you have to set the IO in a try block.

Because it is always a disk operation, that should always in my opinion.

So therefore there can be a little extra check in it be useful and is the
warning in this message right.
(When I give this answer I always do, but the answer was already given).

An error is never good, but Herfried is alway writting by this one
"a real bad error" and that is the only place he does, therefore my OT to
him.

(And why I did not warn this time, I was waiting on that "it has a real bad
error" from Herfried )

:-))

Just my thought about it.

Cor

A path name of more than 128 characters is long, but not extreme by any
means...

It's nice to know of the bug, it's the sort of thing that you would never
have a problem with in development or testing, but you could guarantee that the first real user would have a real long path name.... Murphys Law and
all that!

[Herfried K. Wagner [MVP]]

* "Cor" <no*@non.com> scripsit:

I was waiting for it Herfried.
:-)
A real question, how many people are using paths longer than 128characters,
in a commandline you even cannot type it as far as I know.
On my file system, there are lots of paths longer than 128 characters.
I never typed them in a commandline, but I picked them from a dialog.
So it is an error, however what me triggers are the words "real bad error"

It's IMO very bad, because it can cause wrong behavior of your
application.

--
Herfried K. Wagner [MVP]
<http://www.mvps.org/dotnet>

[Herfried K. Wagner [MVP]]

* "Cor" <no*@non.com> scripsit:

An error is never good, but Herfried is alway writting by this one
"a real bad error" and that is the only place he does, therefore my OT to
him.

It's one of the rare cases I use this sentence. It's a bug
(one of the famous buffer overflow bugs).

--
Herfried K. Wagner [MVP]
<http://www.mvps.org/dotnet>