i have just upgraded my computer to a Sony all in one PC and i have installed all the software i use,, but when it comes to running my application which uses infragistics controls via deployment and via Debugging environment the app crashes as soon as it has to load data into a XamDataGrid with the following error:
Argument Exception was unhandled
Item has already been added. Key in dictionary: 'Infragistics.Windows.Automation.Peers.DataPresenter.CellAutomationPeer' Key being added: 'Infragistics.Windows.Automation.Peers.DataPresenter.CellAutomationPeer'
I have tried tracking down the error but to no avail so any assistance will be greatly appreciated.
The Computer is running Windows 7 Professional 64bit and im using NetAdvantage WPF 2010.3
The issue should be addressed in the latest hotfix (available back in August). You can get the download by going to My Infragistics => Keys and Downloads.
I have tried installing the WPF 2250 Service Release but error still persists
I can't really give you a definitive answer. As you see that method is that of the WPF AutomationPeer class and it is used to obtain the list of direct child automation peers for a given automation peer. WPF determines when those classes are created and it invokes those methods. The automation peers are usually created because some automation/accessibility client is requesting information about the application. If you want to test the automation classes one typically uses something like UISpy or UIAVerify or other automation testing tools but other automation clients (e.g. assistive technology tools, screen interaction recording tools, etc.) would likely cause the peers to be created as well.
Andrew, in case of strong name, the dlls are expected to be signed with public key 7dd5c3163f2cd0cb. If we use our .snk file to strong name then we are running into compilation issues because of mismatch in public key .Our existing binaries which have references with above key not able to detect the compiled binary with different strong name. This is resulting into too many changes in our projects to remove the old dll reference and add the new compiled binary which is affecting QA delivery. We have around mroe than 200 projects in the suite.
Is there anyway I can get .snk file you guys used to strong name your assemblies? In that way we will make sure that the binaries contains public key which depandant binaries are expecting. Let me know any work around for this.
I'm sorry but we do not provide the public/private key file that we use to sign our assemblies as that is used to uniquely identify the assemblies that we have tested and built. If you compile the source then you must update the projects to reference your versions of the assemblies and recompile them.
Thank you, this issue is found in only certain C# projects. I'm not sure why the failure is seen in only few projects and not in all though all the projects has same references.
For example the reference path looks like this for all the projects.
<Reference Include="Infragistics3.Wpf.v9.1, Version=9.1.20091.1006, Culture=neutral, PublicKeyToken=7dd5c3163f2cd0cb, processorArchitecture=MSIL"> <SpecificVersion>False</SpecificVersion> <HintPath>..\..\..\..\public\Infragistics\Infragistics3.Wpf.v9.1.dll</HintPath> </Reference>
Please let me know if you have any clue on this
Unfortunately I do not have a specific set of steps or scenario that will be the catalyst for the issue. Basically the issue is that the RecordAutomationPeer would get the list of child automation peers from the associated RecordPresenter's peer. It would then add in the CellAutomationPeers that represent the cells (since cells are virtualized). At some later point the GetChildrenCore of the RecordAutomationPeer was requested again at which point it did this process again. However since it had manipulated the list instance from the RecordPresenter, if the RecordPresenter returned that same List<AutomationPeer> instance then it would already have the CellAutomationPeers for the record and when the WPF framework was building a dictionary of the peers it blew up because it contained multiple instances of the same AutomationPeer.
OK, settings at the solution level overridden confguration settings at project level. I'm doing the whole recompilation with solution level release settings. will update you for any issues after that.thanks
Andrew, I debugged the code and verified that these assert statements are poping up now and then.
for example Debug.Assert(adjustedScrollPosOfTargetRecord >= 0); is rasing while editing the records. I indeed built the binaries in release mode but the binaries are not dropping at bin/Release instead they always drop in bin/Debug mode. I'm not sure if some other settings are overriding. Can you help us to build the binaries in release mode and if I'm missing something?
Thanks.
I have never seen that assert being raised so I cannot say what is happening. If you want us to look into that you would need to supply a sample that reproduces the issue. Basically the only assert in that routine is veritying that we have exited edit mode (or more accurately that we don't still have a CVP for a cell in edit mode which would/should have been cleared when the cell exited edit mode unless there was a problem there or unless someone tried to force the cell back into edit mode likely on another cell). That may well have been happening in your real application without you knowing since you would only see the assert if you were using a debug build - which you weren't with the release version.
I'm not sure what you are asking. If you are asking about when GetChildrenCore will be invoked as I mentioned I do not know as that is not something that we control. It is controlled/invoked by the WPF framework when something wants to get the children for a given automation peer or possibly when the associated element has been invalidated to update the cache. For anything further on that method you would have to check with MS or use reflector to review the WPF framework's implementation.
As to the OnSorted that is used to raise the Sorted event and from your description I do not know what is the cause of the NRE - it could be within your handling of the Sorted event or something else.
Andrew, our entire suite is compiled with the local fix and when application installed with the fix , I got this assertion failure message in one of our scenarios. I've not completed testing all possible scenarios.Could you verify the reason behind this message? Basically we have a grid component which has combo boxes in two columns added as xam editors. Items can be selected in each of these combo boxes and rows will be added dynamically once selection complete in any single row. While doing random selections, following assertion failure message popped up. This will be real concern for me to release the fix to QA.