Hi Travis,

AutomationPeer stuff usually means some kind of screen reading is going on with the application.  Some program on the users machine is trying to screen read the application.  Programs like Microsoft's Narrator do this.

Did your users provide any steps for reproducing this?  I understand that you are currently not able to reproduce this but I would like to know what exactly your users were doing with the XamDataTree at the time of the exception.  I see that the XamDataTree Unloaded event was fired.  Was the user changing screens or something which caused the XamDataTree to unload?

Maybe looking at some of my code will help you figure out the problem, i have attached the relevant classes, controls etc.  The classes and controls are included, and i just stuck in the methods that call them in the .txt file.

I found an eerily similar issue here:  http://es.infragistics.com/community/forums/t/91777.aspx?PageIndex=1

Has this been "fixed" in the version i am using?  

(InfragisticsWPF4.Controls.Menus.XamDataTree.v14.2, Version=14.2.20142.2024)

Perhaps the problem has been reintroduced?

Hi Travis,

The last part of the call stack in that forum thread looks the same and the issue described in that thread is supposed to be resolved in the version you are using.  There is a slight difference though in that the call stack does not show the issue stemming from unloading the tree.  So it's entirely possible this is a separate issue brought about by different consequences.

I sent the call stack to our development team for them to take a look.  I explained to them that in your application the issue occurs when closing the XamDataTree window.  (this is pretty obvious in the call stack with the Unloaded event).  I will let you know what they say.

Thanks Rob.  I was finally able to create a sample that reproduces the problem (when Narrator is running and works fine when Narrator is OFF).  It doesn't make a lot sense, but it shows the issue.  On close, the collection that is bound to the XamDataTree was being cleared inside a dispatcher.  I still don't understand why this always worked fine before.  OR why running Microsoft Narrator causes it to throw the null exsception.  However, commenting out the clearing of the collection solved the error from occurring.  This still leaves the question of why Narrator causes a problem in the XamDataTree control.  I believe this may be a bug and should be addressed.  I have uploaded the project so you may confirm the issue.  Let me know your findings and if there is a resolution.  Thanks again for your continued assistance.

I'm using .NET 4.5 and have all service packs etc applied to Win 7.

Hi Michael,

Do you have a private support case already open for this?  If so, you can give me the number and I'll link your case to the dev issue as well.

Following this, as I have also raised a support issue on this, but couldn't reliably reproduce.

Yeah, that was an error on my part.  Sorry about that.  In the excitement of obtaining a reproducible sample I didn't read through what you said clearly enough.  Thanks for setting me straight.

Yes, i will can use my workaround in the meantime.  It is actually commenting out the .Clear of the collection for the workaround.  So the fix is to NOT clear it, I believe you erroneously stated above the fix was to clear it, it is just the opposite.  If you look in the sample i provided, there are comments in the ConfirmClose method in CompareBillingVM.cs, you will find a comment '

//this ClearAll method is the offender, commenting it out fixes the problem'

commenting out that line allows the code to run without the exception. Inside of ClearAll(), the bound collection is cleared inside a dispatcher.

Thanks again, I am looking forward to a resolution.