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?

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 don't see any connection between a run-time exception about duplicate keys and a design-time issue with the form being dirtied. I could be wrong, but those seem like two completely separate issues to me.

If you are using threading in your application, then that would be my absolutely #1 suspect for the cause of the run-time Exception. It is virtually impossible to safely use threading and DataBinding together. When you use threads, you have to be in control of the communication between the threads. And if your thread so much as looks at anything on the UI thread, like the grid's DataSource or the BindingManager, or (of course) the grid itself, then it will cause a problem, because you are not in control of the communication between any of those objects. What you are describing here has all the hallmarks of a threading issue - a seemingly impossible exception related to duplicate keys that occurs seemingly at random an is impossible to debug or duplicate reliably. That practically screams threading problem.

Hi,

So I took a look at the files you sent us. The file itself is already corrupt, so it's difficult to tell how that happened from the file contents, but I noticed one thing that is a very strong candidate. I noticed that your form is derived from a base form.

Visual inheritance in DotNet does not work well with collection properties. There are all sorts of problems that occur when you have a control that exposes a collection and then inherit from that form. You can demonstrate these sorts of issues with any control that exposes a collection - for example, the inbox TreeView control. If you were to put a TreeView on a form and add some nodes, then derive from that form and modify the tree nodes collection in any way (modifying, removing, or adding nodes), you would very shortly run into issues where nodes duplicate themselves or disappear.

So I can't be sure, but I strongly suspect that's what's happening here. You probably have a grid on the base form bound to to a data source and it's somehow getting modified and therefore corrupted on the derived form.

The only solution in that case is not to add anything to the collection at design-time. So that would mean binding your grid to the DataSource only at run-time and not int he designer.

OK, have another occurrence of this. I do have some proprietary info in the designer files, though, and would rather not contaminate the evidence by redacting them. I have created a support ticket to upload the files, and referenced this thread. CAS-150742-C3T0P6

Thanks

Hi,

My apologies, I lost track of the thread and forgot you were getting the exception at design-time. Unless your data source exists on a another thread at design-time and is bound to the grid at design-time, it's probably not a threading issue.

So... once this exception occurs, you said you have to restore from a backup. So presumably the form is corrupt at that point and it will reproduce the same exception every time you try to open it. Is that right?

If so, then it might help us to look at the form designer code before and after. So the next time this happens, maybe you could send us the form.cs and form.designer.cs files from before and after the error so we can compare. We might be able to figure out what happened by comparing the two.

Of course, I understand that getting the "before" version might be tricky - depending on how often you back it up. Also, if there is proprietary information on the form or if it relies on other classes in your project, it might not be possible. But that's the best approach I can think of to determine the cause of the error.

I'd tend to agree, except it's not truly a run-time issue. As indicated in the original post and indicated in my other responses, the error occurs in the designer. I try to open the form in the designer and the error appears. Perhaps VS has the threading issue, where it is restating the contents of the form on one thread and managing the infragistics licenses or resources on another. Since I never experience the problem with plain vanilla form objects, I considered the IG controls as being involved in the cause. I like to use them a lot, though, so was interested in getting a solution to this issue.

At this point I have a workaround (pre-build event that backs up the forms) that limits my lost work, and can't afford any more time to investigate root cause.