It has to do with the MDI client and the instantiation order. The issue has to do with threading, basically. The form had not fully instantiated itself into the MDI client. The handle had been created, the MDI parent form had been set, but the searching uses two elements that rely on threading: WaitWindow and the DataLayer. Now at this point, the DataLayer should not be a factor, but the WaitWindow could as well as the BD component. Here is the heirarchy of a browse dialog without any parent:
BrowseDialog (Component) -> BrowseDialog Form
Now when you drop a BD on a form the hierarchy looks like this:
Form -> BrowseDialog (Component) -> BrowseDialog Form
Now when you click the searching button, it would look like this:
Form -> BrowseDialog (Component) -> BrowseDialog Form -> Search (Button Click) -> WaitWindow (Component) -> WaitWindow (Thread) -> WaitWindowForm
Keep in mind that each handle or child relies on the parent as well. Since a form doesn't load on a thread, it is a procedural execution (as it should be). So the form instantiates in a logical order, for example, OnHandleCreated -> OnLoad -> OnCreateControl -> OnShown, etc. So now take your logic, which you had in the Load. Well, at this point, the entire form had not actually completed instantiation and since one builds on top of the of the other using the line of events placed above, the Form in that example and in the code that you had, was still blocking in the Load. When the other windows that rely on a fully instantiated form as well as certain elements (such as the handle and ParentForm properties), then you can get a lock since all code has not executed. So in this example, I moved your code further down the execution chain which prevented the "blockage" and allowed the base object to complete instantiation.
So take the case when you click the cancel:
Form -> BrowseDialog (Component) -> BrowseDialog Form -> Cancel (Button Click)
Using this example, there were no downstream components that relied on the full instantiation of the parent object, thus no lock.
This is a super '"Reader's Digest"example, and this can get really complicated. But in short, when you run into something like this, move your code furhter down the instantiation chain or remove the reliance on the parent altogether (which is not always an option).