NullReferenceException after closing a DockLayoutManager

Hi,

Recently we started encountering null reference exceptions in various scenarios when the DockLayoutManager was being closed. Here is an example stack trace:

2011-09-22 14:20:39,896 [1] FATAL Application.App - Error at top level of Application.
System.NullReferenceException: Object reference not set to an instance of an object.
at DevExpress.Xpf.Docking.DockLayoutManager.OwnerWindowPreviewKeyUp(Object sender, KeyEventArgs e)
at DevExpress.Xpf.Docking.DockLayoutManager.OwnerWindowPreviewKey(Object sender, KeyEventArgs e)
at System.Windows.Input.KeyEventArgs.InvokeEventHandler(Delegate genericHandler, Object genericTarget)
at System.Windows.RoutedEventArgs.InvokeHandler(Delegate handler, Object target)
at System.Windows.RoutedEventHandlerInfo.InvokeHandler(Object target, RoutedEventArgs routedEventArgs)
at System.Windows.EventRoute.InvokeHandlersImpl(Object source, RoutedEventArgs args, Boolean reRaised)
at System.Windows.UIElement.RaiseEventImpl(DependencyObject sender, RoutedEventArgs args)
at System.Windows.UIElement.RaiseTrustedEvent(RoutedEventArgs args)
at System.Windows.UIElement.RaiseEvent(RoutedEventArgs args, Boolean trusted)
at System.Windows.Input.InputManager.ProcessStagingArea()
at System.Windows.Input.InputManager.ProcessInput(InputEventArgs input)
at System.Windows.Input.InputProviderSite.ReportInput(InputReport inputReport)
at System.Windows.Interop.HwndKeyboardInputProvider.ReportInput(IntPtr hwnd, InputMode mode, Int32 timestamp, RawKeyboardActions actions, Int32 scanCode, Boolean isExtendedKey, Boolean isSystemKey, Int32 virtualKey)
at System.Windows.Interop.HwndKeyboardInputProvider.ProcessKeyAction(MSG& msg, Boolean& handled)
at System.Windows.Interop.HwndSource.CriticalTranslateAccelerator(MSG& msg, ModifierKeys modifiers)
at System.Windows.Interop.HwndSource.OnPreprocessMessage(Object param)
at System.Windows.Threading.ExceptionWrapper.InternalRealCall(Delegate callback, Object args, Int32 numArgs)
at MS.Internal.Threading.ExceptionFilterHelper.TryCatchWhen(Object source, Delegate method, Object args, Int32 numArgs, Delegate catchHandler)
at System.Windows.Threading.Dispatcher.InvokeImpl(DispatcherPriority priority, TimeSpan timeout, Delegate method, Object args, Int32 numArgs)
at System.Windows.Threading.Dispatcher.Invoke(DispatcherPriority priority, Delegate method, Object arg)
at System.Windows.Interop.HwndSource.OnPreprocessMessageThunk(MSG& msg, Boolean& handled)
at System.Windows.Interop.HwndSource.WeakEventPreprocessMessage.OnPreprocessMessage(MSG& msg, Boolean& handled)
at System.Windows.Interop.ComponentDispatcherThread.RaiseThreadMessage(MSG& msg)
at System.Windows.Threading.Dispatcher.PushFrameImpl(DispatcherFrame frame)
at System.Windows.Threading.Dispatcher.PushFrame(DispatcherFrame frame)
at System.Windows.Threading.Dispatcher.Run()
at System.Windows.Application.RunDispatcher(Object ignore)
at System.Windows.Application.RunInternal(Window window)
at System.Windows.Application.Run(Window window)...

Our workaround for the time is to derive our own DockLayoutManager class and override some of the methods where we have seen this exception occur such as:

        protected override void FloatingWindowsReposition()
        {
            if (!IsDisposing)
                base.FloatingWindowsReposition();
        }

        protected override void OwnerWindowPreviewKeyDown(object sender, System.Windows.Input.KeyEventArgs e)
        {
            if (!IsDisposing)
                base.OwnerWindowPreviewKeyDown(sender, e);
        }

        protected override void OwnerWindowPreviewKeyUp(object sender, System.Windows.Input.KeyEventArgs e)
        {
            if (!IsDisposing)
                base.OwnerWindowPreviewKeyUp(sender, e);
        }

Our question is, why do we need to do such a check for !IsDisposing before calling the base method? By doing so, we avoid the exceptions and subsequent crash or our application. Is this a bug in the DockLayoutManager?