Hi Andrew,

I do have virtual PC and tried same behavior multiple times but never seen this error. I've asked user for more details on steps and memory dump file if possible which might be useful. Since it is vacation time it may take a week to get a reply. I will respond once I get more details.

Provided dump file does not indicate any contained data but only stack trace of unhandled exception details. Thus does not provide any additional details. Also I am unable to reproduce this error on my Virtual PC so far even with customer provided more exact steps. So it is easy to reproduce for customer but not for me. Further analysis showed me that this error is part of our implemented workbook behavior and raised as part of property changed,

I wondering what owner has changed and from what value. The IWorkbookOwner is internal thus I cannot see any details. During my testing I've noticed once that spreadsheet tabs were reset to default (contained 1 instead of 10+ tabs) with name "Sheet1" while our workbook never containing this name but content was filled with previous sheet our data. Thus I have a feeling that default workbook is reloaded (coming with spreadsheet control itself) on activate and then our workbooks is assigned which causing this problem. 

System.NotSupportedException: Workbooks can not have multiple owners
   bei Infragistics.Documents.Excel.Workbook.RegisterOwner(IWorkbookOwner owner)
   bei Infragistics.Controls.Grids.Core.Spreadsheet.OnWorkbookChanged(Workbook oldWorkbook, Workbook newWorkbook)
   bei Infragistics.Controls.Grids.Core.Spreadsheet.set_Workbook(Workbook value)

I've requested more additional information about connection type to the Virtual PC from customer and screenshot. Any suggestions how I could get more accurate reason for this error? What is stored in IWorkbookOwner?

After getting additional details on this topic I am able to reproduce easy same problem just by using Remote Desktop application. I've tried to create a test sample with single attached behavior but it did not failed so far so something else is involved in this event. From additional logging I was able to figure out that used RegionManager with XamDockManager might be involved in this event chain which is missing in test application. 

Additionally, as I observed before it really creates new instance of SpreadSheet control or existing has been reset since worksheets disappearing but active sheet's data content remains shown. This is very unusual behavior and I am not sure how I could track this change so far. The investigation continues and once I will be able to reproduce the problem in test application I will upload test application.

I will post update later.

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.

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.

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.

Hello Tomas,

Thank you for your update on this matter. I am glad you were able to find the root cause of the issue you were seeing.

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

Hello Tomas,

Thank you for your update on this matter.

I am rather curious how the Workbook that is being bound to the Spreadsheets in your actual application is stored, as that could potentially offer a clue to the underlying reason that this issue is happening. As mentioned previously in this forum thread, I was able to reproduce the error you are seeing by trying to bind a single instance of a Workbook to multiple XamSpreadsheet control instances. This is something that is unsupported, and it is expected that an exception is thrown in that circumstance.

This makes me wonder if somewhere in your actual application you may be binding the same instance of a Workbook to multiple XamSpreadsheet instances, perhaps when the application is reloaded. Something you might be able to do to check this in your actual application is to print out the hash code of the Workbook and the hash code of the XamSpreadsheet that it is being assigned to just before assigning it, although this might prove to be a bit more work if you are binding the Workbook. If you find that more than one instance of a hash code shows up for a Workbook assigning to multiple different XamSpreadsheets (you can add the hash code of the spreadsheets to check this too), you can discern that it is being applied to multiple instances of XamSpreadsheets, which is an operation that – as mentioned above - is invalid.

I also have to wonder how much of this error happening and the reloading of views is reliant on the Prism implementation that you have in place. It’s worth noting that Prism is not actually an Infragistics product, and as such is not something that we provide support for.

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