Hello Tomas,

The sample project I tried did not use a XamDockManager or a remote desktop session, as I was awaiting a more concrete set of reproduction steps from your end or a sample project that reproduces it.

Your mention of the XamDockManager a couple of updates ago only sparked the idea in my mind that you may have multiple instances of the XamSpreadsheet bound to the same instance of the Excel Workbook in this case, and so to test that, I simply put two XamSpreadsheet controls into a WPF Window and assigned a single Workbook to both of them. This reproduced the exception you are seeing, but very likely not in the same route that you are currently doing.

I am curious to know if perhaps something that you could use as a workaround in this case would be to use a flag that determines whether or not a particular Workbook has already been assigned to a XamSpreadsheet or not as this could potentially prevent your code that is assigning the Workbook to a XamSpreadsheet instance from firing again for a different XamSpreadsheet and the same Workbook?

Something that might be worth checking as well is the code-path that is followed when this exception happens. Where in your code are you trying to apply the Workbook to a XamSpreadsheet instance? For example, is it happening in a Loaded event or something along those lines?

Please let me know if you have any other questions or concerns on this matter.

Hi Andrew,

Can you provide your sample application? I would like to try to adapt to my known scenario with single scenario of this control and check if problem still persist on RDP session.

During analysis I noticed that other views reloaded same way as this one but they don't have such a side effects like spread sheet control. Based on stack trace in my very first called view no other our views are involved, thus still causing problem understanding the problem. The stack trace is quite long and it involves mainly Windows calls however few related to Infragistics:

 at EafClient.Editor.CellAutomation.EquipmentDictionary.Views.EquipmentDictionaryEditorView..ctor() in D:\_PROJECTS\EAF_MAINT\EAF Mango\v3.x_Maint\Implementation\EafClient.Editor.CellAutomation\EquipmentDictionary\Views\EquipmentDictionaryEditorView.xaml.cs:line 23
   at System.RuntimeType.CreateInstanceDefaultCtor(Boolean publicOnly, Boolean skipCheckThis, Boolean fillCache, StackCrawlMark& stackMark)
   at System.Activator.CreateInstance(Type type, Boolean nonPublic)
   at System.RuntimeType.CreateInstanceImpl(BindingFlags bindingAttr, Binder binder, Object[] args, CultureInfo culture, Object[] activationAttributes, StackCrawlMark& stackMark)
   at System.Activator.CreateInstance(Type type, BindingFlags bindingAttr, Binder binder, Object[] args, CultureInfo culture, Object[] activationAttributes)
   at System.Activator.CreateInstance(Type type, Object[] args)
 ...
   at Infragistics.Windows.DockManager.SplitPane.MeasureOverride(Size availableSize)
   at System.Windows.FrameworkElement.MeasureCore(Size availableSize)
   at System.Windows.UIElement.Measure(Size availableSize)
   at Infragistics.Windows.DockManager.DocumentContentHostPanel.MeasureOverride(Size availableSize)
   at System.Windows.FrameworkElement.MeasureCore(Size availableSize)
...
   at System.Windows.UIElement.Measure(Size availableSize)
   at Infragistics.Windows.DockManager.DockManagerPanel.MeasureOverride(Size availableSize)
   at System.Windows.FrameworkElement.MeasureCore(Size availableSize)
   at System.Windows.UIElement.Measure(Size availableSize)
...
   at System.Windows.ContextLayoutManager.UpdateLayout()
   at System.Windows.UIElement.UpdateLayout()
   at Infragistics.Windows.DataPresenter.GridUtilities.ProcessAsyncInvalidationsImpl()
   at Infragistics.Windows.DataPresenter.GridUtilities.ProcessAsyncInvalidations()
   at System.RuntimeMethodHandle.InvokeMethod(Object target, Object[] arguments, Signature sig, Boolean constructor)
   at System.Reflection.RuntimeMethodInfo.UnsafeInvokeInternal(Object obj, Object[] parameters, Object[] arguments)
....

By the way, have you tried your sample application using fallowing steps:

• Connect to any other PC using Remote Desktop session
• Start the application containing DocManager with PaneHealderPresenter and content page containing single Spreadsheet control with preloaded workbook and few worksheets
• Disconnect Remote desktop connection
• Wait a sec and then Connect to the same PC (this should show signing in screen since during disconnect it locks the PC)
• After showing desktop I get unhandled exception (shows error message but allows to continue). It is not necessary for application to be active as well as to active content page. We have problem even with not active tabs in content region. So say I loaded 2 views containing one spreadsheet in each page (same type but not related to each other), after reconnect both views affected by same problem.

Hi Andrew,

Thanks for very descriptive definition of rootcause as well as time spent on reproduction what I was suspecting. I will try to determine why the control is reloaded during reconnect. Our application is using only 1 control in same editor but something is resetting the control during RDP connection event and resulting in strange behavior.

Hello Tomas,

I have been running a XamSpreadsheet application against our internal source code to see what the process is for the RegisterOwner issue that you are seeing, and it appears that when the XamSpreadsheet’s Workbook property changes, we check for an old workbook, and if one exists, clear its Undo history and unregister its owner. Then, we register an owner for the new one. An exception is thrown if the cached owner for the Workbook already exists, and that is the only way that this exception happens.

The “owner” that is created in this case is an instance of WeakWorkbookOwner, and it is used primarily in transaction histories for undo operations in the Workbook for usage within the XamSpreadsheet.

The XamDockManager part of this made me think of what could potentially cause this, and I tested the scenario in which there are multiple instances of the XamSpreadsheet with the same instance of the Workbook assigned. In doing so, I reproduced the exception you are seeing, which leads me to believe that somewhere in your application, a new instance of XamSpreadsheet is getting created and has the same Workbook assigned to it, which is not a supported action. Perhaps this information will help you to track down the exception in your application?

Please let me know if you have any other questions or concerns on this matter.