Bug in FolderBrowserDialog!

  • Thread starter Thread starter BrianGenisio
  • Start date Start date
B

BrianGenisio

Hi all,

I am having a problem with the FolderBrowserDialog. I have attached an
application that exercises the problem by calling the
FolderBrowserDialog. When I Run this app as a different user, and
click "Make New Folder", the dialog does not update. (The new folder is
created... the dialog does not update) If I run this app normally, the
dialog updates normally.

To replicate the issue, compile this appliation, and run it as a
different user on your system by right-clicking and choosing "Run As".

Does anyone know how to fix this problem?

*Hint: This same problem exists with the Win32 function
SHBrowseForFolder. The .NET FolderBrowserDialog control is obviously
just a wrapper to this Win32 call.

Code:

using System;
using System.Windows.Forms;

namespace FolderTest
{
class Test
{
static void Main(string[] args)
{
FolderBrowserDialog folderBrowser = new
FolderBrowserDialog();
folderBrowser.ShowDialog( );
}
}
}
 
i confirm this behaviour. i also notice that 'My Documents' is an empty
folder, when run as a different user. i guess this makes sense. but there
is no excuse for not being able to create a new folder properly via the
FolderBrowserDialog.

any response from the MS camp?
 
Does anyone know how to fix this problem?

FYI, this problem is really a side effect of the fact that shell
notifications (as in the SHChangeNotify* family of APIs) can't be
recieved in a runas process. I don't know if that's by design for
security reasons or not. The folder browser dialog waits for a
SHCNE_MKDIR notification before displaying the new folder but never
gets it. Unfortunately I don't know any workaround.

static void Main(string[] args)
{
FolderBrowserDialog folderBrowser = new
FolderBrowserDialog();
folderBrowser.ShowDialog( );
}

Not that it will help with this problem, but for your code to really
be correct you should add the STAThread attribute to Main.


Mattias
 
OK, more insight...

If I run this code, and go into the C: drive, I am successful in making
a new folder!

Here is what I think is going on... When we are looking at the Desktop
folder, we look at the user's actual folder, but when the notification
is being registered, it is being registered with the current user's
desktop!

I verified this by writing a test that registered on CSIDL_DESKTOP.
Even if I run the app as a different user, I get notifications when I
make changes to MY desktop, not the different user. The same is
probably true for CSIDL_MYDOCUMENTS.

I still do not know how to fix this, but I know that if I change the
root folder from SpecialFolder.Desktop to SpecialFolder.MyComputer, I
have a temporary fix.
 
I'm seeing a problem where the SHBrowseForFolder isn't getting any updates on
certain machines. In my case, the logged in user is runnng the app and he is
a member of the Administrators group. Other than security reasons, what
would cause the SHChangeNotify* events to not be sent?

Thanks,
Eric

Mattias Sjögren said:
Does anyone know how to fix this problem?

FYI, this problem is really a side effect of the fact that shell
notifications (as in the SHChangeNotify* family of APIs) can't be
recieved in a runas process. I don't know if that's by design for
security reasons or not. The folder browser dialog waits for a
SHCNE_MKDIR notification before displaying the new folder but never
gets it. Unfortunately I don't know any workaround.

static void Main(string[] args)
{
FolderBrowserDialog folderBrowser = new
FolderBrowserDialog();
folderBrowser.ShowDialog( );
}

Not that it will help with this problem, but for your code to really
be correct you should add the STAThread attribute to Main.


Mattias
 
I know this is an old thread but had the same issue and have a hacky solution for anyone interested.

we experienced this problem as we have a web set up app that needs to run in elevated privileges mode and the folder browse dialog gets this issue which is
if you click new folder, type in a name but don't press enter or click some where so the name edit text box remains visible, and then click OK. The folder on disk is renamed correctly, but the folder browse dialog returns the path with "New Folder" not the renamed folder.

my fix was to use code to find the newest folder in the current directory as follows

Dim strSelectedPath As String = FolderBrowserDialog1.SelectedPath
Dim strPathStart As String = ""

If IO.Directory.Exists(strSelectedPath) = False Then ' Folder not found (most likely the bug described above)

' Set back to the folder where the new folder was created
strPathStart = Strings.Left(strSelectedPath, InStrRev(strSelectedPath, "\") - 1) ' Get the folders before "New Folder"
strSelectedPath = ""

If IO.Directory.Exists(strPathStart) Then
Try
Dim di As IO.DirectoryInfo
Dim diNew As IO.DirectoryInfo = Nothing

Dim diMain As New IO.DirectoryInfo(strPathStart)
For Each di In diMain.GetDirectories()
Try
If diNew Is Nothing OrElse di.CreationTime > diNew.CreationTime Then
diNew = di
End If
Catch ex As Exception ' In case we don't have permission to another folder in the same level (should to the one we just created)
End Try
Next di

If diNew IsNot Nothing Then
strSelectedPath = diNew.FullName
End If

Catch ex As Exception
End Try
end if

' strSelectedPath is the correct path
 
Last edited:
Back
Top