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