Thanks. I was expecting to see some of our own methods in the call stack if it was an error in our event handlers but that may not be the case. I don't see any mouse click handler or custom creation filter that we have for the dock manager. However I do see PaneButtonClick, PaneActivate and PaneAfterHideFlyout events wired. Some of these events use e.Pane and assume that it isn't null or disposed and perhaps that is not the case. I believe the user also received this error by simply clicking the close button on a particular pane.

The odd thing is this doesn't seem to happen for any other of our 400 users, just this one user on Vista in a limited scenario. Strange. I'll look at adding some more safety checks in and around the event handlers.

After some more research, it appears to be a problem with our use of UltraDockManager's SaveAsXml and LoadFromXML persistence methods. We automatically save and load the user's docking layout but sometimes, somehow the state gets serialized in such a way that when it is later loaded panes can be null or be there but give errors when you start interacting with them.

I seem to remember somewhat related issues during development with the "aggressive" serialization of all the docking properties and conflicts between loading previous options and programatically wanting to enforce certain settings. We also had sporadic startup errors restoring the layout where we had to trap exceptions, delete the docking layout settings, and recreate default settings. This is a similar situation that just manifested itself in a different manner.

The user was able to reset her docking settings with an option in the app but I am worried it might come back. It could very well be in how we are using the control but the only definitive way I know to avoid this issue is to avoid using the built in docking serialization and just reset the layout each time the app is run, or manually save certain parts of the docking state ourselves with our own mechanism.

Hello, ­­­­­

I am just checking about the progress of this issue. Let me know If you need my further assistance on this  issue?

Thank you for using Infragistics Components.

Hello ,

If you are able to isolate the issue in a small sample, in order to be able to reproduce it on my machine, then I will be able to investigate this further for you.

I am waiting for your feedback.

I think maybe you might be misunderstanding what we are doing. Initially we simply load a default layout XML file that we manually save once when things are laid out as desired. Later the user can make changes to the docking layout and before exiting the app we save that layout. The next time the user runs the app we load that layout file again. After the layout is loaded succesfully we set a few properties in code to make sure there are a few things that are consistent (or perhaps setting dynamic data that has changed since the xml file was saved).

Sometimes however when the dock manager serializes its layout, it does so in such a way that it has trouble deserializing it when it is next loaded. If and only if an exception was generated through loading the layout, then we simply delete the user's "corrupt" layout XML file and replace it with our original default layout XML file that we know works.

From the point it is saved to the point it is loaded, we are not doing anything in our code - it's just Infra Save and Load. When the data occasionally gets corrupt it is in that window.

Normal 0 false false false EN-US ZH-TW AR-SA

Hello,

When you load UltraDockManager’s layout, it is not very good approach to delete docking layouts and to make changes into the layout trough the code, because you could miss to remove a pane from the panes collection in the docked areas. You said that you had sporadic startup errors so I think that the changes made into the UltraDockManager’s layout, causing your issue so when you reset the UltraDockManager’s layout you do not get exceptions during the saving of the UltraDockManager’s layout.

Please let me know if you have any further questions.