I was playing around with the BrowseDialog and decided to try and show the BrowseDialog before the form shows. I just put a call in the form's load event and it worked great.



However, if the form is an MDI form, when I click on the Search button on the browse dialog, it just hangs.



If the form isn't an MDI child form (MDIParent property set), this works great. On the MDI form, if I just open the form, then use the browse button on the MaintenanceFormToolstrip, it works great. Not sure if this is a bug or if I don't have something configured correctly. Knowing that this might be a bit hard to understand, I'm attaching a sample solution. It has three projects within it. Two are EXE projects, to show the differences. Follow these steps after unzipping it:



TO DEMONSTRATE NON-MDI

1. Open the solution.

2. Select the top project, "BrowseDialogFormOpenTest". If it isn't already, make it the startup project.

3. Hit F5 to run, select strataframesample db.

4. Click on View Customers, browse dialog is shown

5. Click on Search, searching windows is shown, then results appear

6. Click on OK, Customers form is shown loaded with data...Great, exactly what we wanted.



TO DEMONSTRATE MDI IS NOT WORKING

7. Select the bottom project, "MDIClientTest". If it isn't made the startup project, do so now.

8. Hit F5 to run, again select strataframesample db.

9. Click on View Customers, browse dialog is shown.

10. Click on Search. Nothing happens. App is unresponsive. Oops, something isn't working.

11. Alt-Tab to Visual Studio, stop app via debugger.



TO DEMONSTRATE NON-FORM LOAD METHODS WORK

12. Hit F5 to run again.

13. Click on View Customers, browse dialog is shown.

14. Click on Cancel, the customers form is shown, with no data.

15. Click on Browse, browse dialog is shown.

16. Click on Search, searching windows is shown, then results appear.

17. Click on OK, customers form is shown, loaded with data.

This will work better if I actually attach the solution...

Bumping to Trent

Simple fix, not a bug.  You are trying to instantiate a modal dialog before the parent form (CustomersForm) actually has a chance to fully instantiate.  This is a .NET related instantiation issue.  To resolve the issue do this:

Problem solved

I love those simple fixes

Edhy Rijo

Me too ... or at the very least...when it is not my fault

Humm, we can always blame Dustin (Hi Dustin!)

Ivan, don't worry, so far you are safe for this kind of blame

Edhy Rijo

Oh, I blame Dustin all of the time....and I have no problem blaming Ivan whatsoever!

OK, that worked.



I don't understand why, though. The browse dialog is shown, just the searching doesn't work. The Cancel button works . So the form is getting instantiated and it is shown and at least one of the event handlers is working. So, what is missing in the Load event that is there during OnShown?

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:

Now when you drop a BD on a form the hierarchy looks like this:

Now when you click the searching button, it would look like this:

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:

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).