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.

I have the exact same problem using Infragistics2.Win.UltraWinDoc.v10.3 (10.3.20103.1000). In my case I'm seeing it with about 2 users out of about 2000.

The lack of a stack trace is due to how the exception is being handled in the FireEvent method. Using Reflector I can see code like the following in that method:

catch (Exception ex)
{
    throw ex;
}

Re-throwing an exception using "throw ex" instead of just "throw" destroys the stack trace and is a big no-no (I'm looking at you Infragistics team).

I'm hoping I could persuade you to make the code change and release a patch. I'm fairly certain that with the entire stack trace we would be able to diagnose the problems we're having.

What do you say? Service release?

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.