<(E-Mail Removed)> wrote in message
news:%23Xq%(E-Mail Removed)...
> No matter what I set it to its ALWAYS visible, so the propset is pointless
> on this build that I have which I have no idea what version it is. Its
> windows 2000 sp4 with latest hotfixes using automatic updates SO i would
> guess its the latest.
>
> Its just not possible to hide it on this configuration. On my rig, its a
> bug. Plain and simple.
>
I did a test on a win2k system with IE5 and I did have this problem. My
guess would be this feature came with IE6, installing that should work,
however if the feature relies on XP features then you will have to upgrade
to use that feature. As I said, its something that relies on a specific
windows feature and should be documented as such, that doesn't make it a bug
in the framework however, so much as a bug in the documentation.
>
>
> "Daniel O'Connell" <onyxkirx@--NOSPAM--comcast.net> wrote in message
> news:(E-Mail Removed)...
> >
> > "Daniel O'Connell" <onyxkirx@--NOSPAM--comcast.net> wrote in message
> > news:%(E-Mail Removed)...
> > >
> > > <(E-Mail Removed)> wrote in message
> > > news:(E-Mail Removed)...
> > > > Hi,
> > > >
> > > > The following code shows the FolderBrowserDialog = broken.
> > > >
> > > > FolderBrowserDialog folderDialog = new FolderBrowserDialog();
> > > > folderDialog.ShowNewFolderButton = false;
> > > > folderDialog.ShowDialog();
> > > >
> > >
> > > I can't repo this bug. Setting ShowNewFolderButton to false does
indeed
> > work
> > > correctly on my machine, what version of the framework are you using?
> >
> > Upon further research, it appears that the functionality
> ShowNewFolderButton
> > uses to hide the new folder button is relativly new, debuting in version
> 6.0
> > of the library that offers it(either shlwapi.dll, shell32.dll or
> > ComCtl32.dll), which is only availablewith windows xp(as far as
> ComCtl32.dll
> > and shell32.dll goes) or IE 6.0(which redistributes shlwapi.dll), the
> > version of windows and IE are you running may be of more importance than
> the
> > framework version. This would qualify as a bug in documentation instead
of
> a
> > bug in the class itself, it should be specified when and where this
> > functionality will work. I would, however, suspect it is not in ComCtl32
> > because the 6.0 version of the common control library requires a
manifest
> to
> > use and includes the xp style controls(if memory serves), which I do not
> > believe the framework to do on its own.
> >
> > >
> > > > Setting ShowNewFolderButton to false does bugger all. If I set
this
> > to
> > > > false it is STILL shown. Genius.
> > > >
> > > > There is also NO WAY to set the root directory to MY OWN path. It
> MUST
> > > be
> > > > a SpecialFolder , can we have this so we can set it to any path of
our
> > own
> > > > choosing?
> > >
> > > IMHO, this feature shouldn't exist, period. I don't particularly care
> for
> > > applications that limit my choices on where to store a file. However,
> > > considering this feature *probably* relies on the shell, there may not
> be
> > a
> > > way in the system to do it period, instead of it being a strict .NET
> > > implementation limitation. One way or another, it should be possible
to
> > > choose other shell extensions(outside of the SpecialFolder enum) even
if
> > it
> > > is not possible to choose a particular path, this however is a
> limitation
> > of
> > > properties as a whole and I would not expect to see this changed in
the
> > > foreseeable future.
> > >
> > > >
> > > > Thanks
> > > >
> > > >
> > >
> > >
> >
> >
>
>
|
Similar Threads
