Has been occurring for a while now from version 12+; currently trying to use v13.2.20132.2098. It just cost me another 4 hours’ work today, so I've come here.
I'll be going along doing my work in VsiualStudio 2012, and things will be fine, but then suddenly this error will crop up when trying to open the designer for a form containing Infragistics controls:
Key already exists Parameter name: Key Instances of this error (1) Call Stack : at Infragistics.Shared.KeyedSubObjectsCollectionBase.ValidateKeyDoesNotExist(String key, IKeyedSubObject ignoreObject)at Infragistics.Shared.KeyedSubObjectsCollectionBase.ValidateKey(String key, IKeyedSubObject ignoreObject)at Infragistics.Shared.KeyedSubObjectsCollectionBase.InternalAdd(IKeyedSubObject obj)at Infragistics.Win.UltraWinGrid.ColumnsCollection.InternalAdd(UltraGridColumn column)at Infragistics.Win.UltraWinGrid.ColumnsCollection.Add(Object obj)at Infragistics.Win.UltraWinGrid.ColumnsCollection.AddRange(Object[] columns)
What I believe is happening is that every time I go to debug the app, the Windows Form Designer code for all the Infragistics controls gets re-generated. I can see differences between two successive iterations of the designer file; appearance instances get renumbered, grid column instances get renumbered, band instances get renumbered, etc. If I happen to have the designer form open when I start the debug, then the odds of this regenerated code getting out of alignment are raised greatly, but it is by no means a sure thing that having the designer closed when debugging will keep the problem from happening. When it gets out of alignment, this error is presented, with nothing to do but hope I made a recent backup before the debug, or wading through 1000's of lines of designer-generated code looking for duplicates.
So, anyone else experiencing this? Is it an aspect of Visual Studio, or Infragistics, that this designer code re-generation even occurs? Anyone have a solution?
I spent the last 4 hours building & testing a trial project attempting to reproduce the error, with no (bad) luck. What I do see is that at some point I make some change somewhere that from there on every time the form is opened in the designer, VS immediately indicates that the form has changed. I was grasping at container levels as a possible contributing factor, due to the situation only seeming to occur on those forms where I have a complex organization, usually involving several nested layers of IG controls. Not sure where that threshold level is (can't afford any more time today/foreseeable future), but it is my thought that this file change indicator is pointing towards the problem. If even opening the form in the designer causes it to restate all the instances in the form.designer.cs file, then my error crops up when that restatement makes a mistake. My most recent case of the error I discovered that it added an extra "Band 0" to one of the grids.
Threading may be a contributor, but not sure how creating a backgroundworker in code can affect VS where I'm trying to design the form: that is where this error shows up. In the most recent case, a completely different section of the application does use a bgw, but not the forms I was working in.
The error may in fact have nothing to do with the infragistics controls, just that they are usually used in the forms I'm working with, and on which I've experienced this error. I can't recall it occurring on any plain vanilla windows forms. It may be a "feature" of VS, my install, or my dev environment. Not necessarily looking for you guys to "fix" anything; unless you have some means of preventing VS from renumbering/naming/etc. instances of your controls, finding what the threshold for the error may take longer than the maintenance I currently have to do with pre-build backups, etc.
Hi,
I can't see any reason why the contains should matter. The error is telling you that something in the code is trying to add an item to a collection and it can't because an item with that key already exists in the same collection. So I can't see any way that the container could ever have any effect.
My first guess would be that this is a threading issue. Are you using threads in your application? That would explain the error and also why it happens so intermittently.
If that's not the case, and you are not using threads, then my next guess would be that this is a bug in the grid. But there's not much we can do about that without being able to reproduce it. Of course, if you are using an older version of the grid, you might want to consider getting the latest service release, just in case this is an old bug that is already fixed.
How to get the latest service release - Windows Forms - Service Releases
Thanks for the follow-up.
That is the entire stack, or at least as much as the IDE gives me. The error seems to occur (/most) on those forms where I have multiple levels of containers (i.e. 2 grids in a panel in a form, etc.). I cannot say I can reliably reproduce the error, as things seem to work correctly for long enough to lull me into a sense of complacency and skip the habit of backing up the designer files before every build. Then along comes an instance like last week where I lose work due to the error and no recent-enough backup. If I get a chance in the next few days I will attempt to create an example project; it strikes me that a sufficiently complex project from the online samples may work: are there any where there are multiple levels of containers?
Hello,
We are still following this forum thread.
Please feel free to let us know if you still have any questions on this matter.
Can you post the entire call stack? You only posted a small portion of it here so I can't get the whole picture.
Can you reproduce the exception reliably? If so, could you send us a small sample project that we can use to reproduce it? If the problem occurs at design-time, then the code shouldn't even matter, we would just need a solution with the form that causes the error.