Ivan is correct in regards to a debug environment. Things fire slightly differently when in a debug environment which can cause a modality issue. However, you can control the parent or owner of any dialog you call, including a browse dialog. You can pass in a IWin32Window that will tell the modal form being called to whom it belongs. This can prevent these types of issues. The issue you are running into can happen at run-time as well under certain conditions and is related to Windows and the handle management. The deeper that you go in modality, the more possibility there is for this to happen.
That is why they introduced this logic, way back when, so that you can complete control of ownership instead of the ownership being interpreted. My most recent frustration with this was dealing with type editors. In our medical application we have our own screen generator to build charting screens. We have used the PropertyGrid with many customizations. But the beauty is that we can take advantage of the type editors, etc. Modality and window ownership goes to a new height in this environment!
So this logic can be very help then.
Just FYI, most likely won't resolve a debug scenario, but it is the run-time that really matters.
using System;
using System.Collections.Generic;
using System.Text;
namespace MicroFour.StrataFrame
{
using System.Windows.Forms;
public class Win32Window : IWin32Window
{
#region [ Constructors ]
/// <summary>
/// Default constructor
/// </summary>
/// <param name="hwnd"></param>
public Win32Window(IntPtr hwnd)
{
this._hwnd = hwnd;
}
#endregion
#region [ Public Properties ]
private IntPtr _hwnd;
public System.IntPtr Handle
{
get
{
return _hwnd;
}
}
#endregion
}
}
You then use the class like this. Let's assume I am on a form calling a modal form:
MyModalForm f = new MyModalForm();
f.ShowDialog(new Win32Window(this.Handle));
Any control that has a handle can be used.