We use cookies to give you the best experience on our website. If you continue to browse, then you agree to our privacy policy and cookie policy. Image for the cookie policy date

Saving the state of controls in DockingManager

I have created a simple application (included) to help demonstrate a problem I am having with DockingManager. This application is simply a MDI form with a menu which is used to create tabbed MDI forms. However, I need the forms to have the functionality provided by DockingManager, so the created forms are controls of the docking manager, but when they are created, they are set as SetAsMDIChild(). The application attempts to save itself so when it is reopened the form windows which were open on close, are reopened in their previous state as well. I am using the LoadDockState and SaveDockState along with the AppStateSerializer to save this information. The problem I encounter is when I first start the application and create Form A and then Form B (via the Create Form menu), and then close application. Then restart, I see Forms A and B (which is correct), however, when I attempt to close the application (by clicking on the X in the top right), Form A becomes a dockable control and the application does not close (and the ability to close does not occur). I believe I am doing everthing correctly. Could you tell me if I am doing something wrong or there is a bug in the dockingmanager tool? Thanks, Vikram.

4 Replies

AD Administrator Syncfusion Team October 20, 2003 07:31 PM UTC

Hi Vikram, Thanks for the sample. I have tested for this issue here and have observed the above mentioned behavior. I have notified the development team about this problem and will update you on this shortly. Thanks for your patience. Regards, Guru Patwal Syncfusion, Inc.

DM Desis Machino October 22, 2003 12:25 PM UTC

Just wanted to know if there was any ideas on what was wrong. Also, as a temporary fix, I force the application to close by calling Application.Exit() in the From.Closing event handler (however, this solution is not acceptable). In any case, I am able to exit the application, but, when you start the application, and create Forms A, B, and C, and make c dockable, and close B, and close the application and restart. The state of C is tabbed and not dockable as it was when it was closed. However, if (in the sample included) you comment out the form close (((Form)arg.Control).Close()) in DockVisibilityChanged, the state is saved correctly. Im not sure if this problem is related, but I wanted to point it out while you are looking at this. Vikram.

AD Administrator Syncfusion Team October 22, 2003 01:06 PM UTC

Hi Vikram, Thanks for the sample application and the update. I have tested the sample here and have observed the above mentioned behavior. I will forward this to the Development Team, and will keep you updated on the developments. Thanks for your patience and cooperation. Regards, Guru Patwal Syncfusion, Inc.

PS Prakash S Syncfusion Team October 23, 2003 04:44 PM UTC

Hello, The problem is actually caused by a bug in the .NET 1.1 Framework that prevents a Form from being closed if a child control that has the focus is unparented from the parent Form under certain activation conditions. It is this scenario that is causing the problem in your sample application. When you set the new Form to be an MDI child window through the DockingManager.SetAsMDIChild() call in the 'AddControl(Form f)' method and later on when this MDI child is unparented during the DockingManager.LoadDockState() call, the above mentioned bug manifests. An easy way to workaround this condition is to remove the 'DockingManager.SetAsMDIChild(Control, bool)' call from the 'AddControl(Control)' method and instead invoke SetAsMDIChild() from the MenuItem.Click handlers. This will ensure that only newly created forms are set as docking windows and those that were previously loaded are reinstated to their saved dock state. Also, I did notice that you have attempted to call SetEnableDocking() and dispose off the dockable controls from the DockingManager.DockVisibilityChanged event handler. This approach is not advisable as the docking windows are still an integral part of the DockingManager's control set when the DockVisibilityChanged event occurs. A better approach would be to just add the control to a temporary list and dispose it later from within an idle time cleanup routine. Prakash Syncfusion

Live Chat Icon For mobile
Up arrow icon