This may not be enough to go on but thought I might try anyway - a user of ours is getting a null reference exception with the dock manager after she closes a form in our app. The call stack doesn't have any of our code methods, it's all Infragistics. So far I have been unable to reproduce the issue. I have more info in an error report (screenshot, computer info etc.), should it be needed but I'd have to scrub it first. I don't have a sample app to reproduce the issue. Any ideas? Maybe a known issue?
Normal 0 false false false EN-US X-NONE X-NONE
Time of Error: 1/19/2012 8:40:10 AM
Exception outermost view of call stack
--------------------------------------------------------------------------------
Exception type: System.NullReferenceException
Source: Infragistics2.Win.UltraWinDock.v10.2
Source Assembly: Infragistics2.Win.UltraWinDock.v10.2.DLL
Source Assembly Version: 10.2.20102.2109
Source Type: Infragistics.Win.UltraWinDock.UltraDockManager
Source Method: Void FireEvent(Infragistics.Win.UltraWinDock.DockManagerEventIds, System.EventArgs)
Debug Build?: True
Message: Object reference not set to an instance of an object.
Stack Trace:
at Infragistics.Win.UltraWinDock.UltraDockManager.FireEvent(DockManagerEventIds id, EventArgs e)
at Infragistics.Win.UltraWinDock.UltraDockManager.NotifyPossibleActivePaneChange()
at Infragistics.Win.UltraWinDock.UltraDockManager.ActivatePane(DockableControlPane pane, Boolean force)
at Infragistics.Win.UltraWinDock.DockableControlPane.Activate()
at Infragistics.Win.UltraWinDock.PaneCaptionButtonUIElement.OnMouseDown(MouseEventArgs e, Boolean adjustableArea, UIElement& captureMouseForElement)
at Infragistics.Win.UIElement.OnMouseDown(MouseEventArgs e, Boolean adjustableArea, UIElement& captureMouseForElement)
at Infragistics.Win.ControlUIElementBase.ProcessMouseDownHelper(Object sender, MouseEventArgs e)
at Infragistics.Win.ControlUIElementBase.ProcessMouseDown(Object sender, MouseEventArgs e)
at Infragistics.Win.Utilities.ProcessEvent(Control control, ProcessEvent eventToProcess, EventArgs e)
at Infragistics.Win.UltraWinDock.DockControlBase.OnMouseDown(MouseEventArgs e)
at System.Windows.Forms.Control.WmMouseDown(Message& m, MouseButtons button, Int32 clicks)
at System.Windows.Forms.Control.WndProc(Message& m)
at System.Windows.Forms.ScrollableControl.WndProc(Message& m)
at System.Windows.Forms.ContainerControl.WndProc(Message& m)
at System.Windows.Forms.Control.ControlNativeWindow.OnMessage(Message& m)
at System.Windows.Forms.Control.ControlNativeWindow.WndProc(Message& m)
at System.Windows.Forms.NativeWindow.Callback(IntPtr hWnd, Int32 msg, IntPtr wparam, IntPtr lparam)
Hello ,
I have reviewed your call-stack and it seems to me that there is some code, which has tried to access UltraDockManager’s pane, during of closing of the form (while the from disposes its child components) . This explain NullReferenceException when closing of the form. Also as far as I can see from the call-stack, it seems that have some code on MouseClick event of the UltraDockManager (or you are using Creation Filter in order to enters some customisations in your UltraDockManager), which trying to access PaneCaptionButtonUIElement, so I think that this issue occurs in more specific scenario, not just when customer presses close button on the form.
Please let me know if you have any further questions
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.
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.