I am 99.9% sure this is the EXACT same issue I was having a while back, the removing the previously autogenerated columnsets thread I started a while back.
Right after compiling the attached project, Visual Studio 2008 SP1 crashes. I am darn close to possitve that this is an issue with how the UltraGrid uses a collections ITypedList interface. Here is how I have come to that conclusion:
The goal is to allow home grown attributes on business objects. To achieve this goal when the business objects are in derivatives of IList, the collections need to implementation of Microsofts ITypedList. After making some changes to the code there was a new and serious bug introduced when trying to display a collection with a custom ITypedList, there was an endless loop. After much digging it was discovered the issue is in the custom implementation of ITypedList.
In the quest to fix the bug, this article shed a lot of light on the subject: http://weblogs.asp.net/fbouma/articles/115837.aspx
I opted to start with a baseline that does NOT use the custom ITypedList and build from there. The problem I have run into is that Visual Studio keeps crashing and is very sluggish when working with the UltraGrid control. I believe the actual business objects are correct because Visual Studio is displaying the structure correctly inthe Data Source view:
When I compile the program VS2008 does compile it, then it crashes. If the program is run outside of VS2008, it runs as expected.
My speculation is that there is a bug in the design time code which uses the ITypedList interface of the datasource of the UltraGrid control.
When the CompanyCollection implements the buggy custom ITypedList interface, VS2008 still shows it correctly, but the UltraGrid does not show it correctly, nor does it run. This custom implementation is NOT included in the project. If you would like to have it, please let me know and know where I can email, I cannot post it on an open forum.
Sam
scarleton said:Is this to say that it is your policy to not test older service releases? Just wondering what the official policy is ;)
I'm not sure what you mean. As a matter of course, I don't keep older versions of our controls on my machine, because there's not much point. I always keep up to date with the latest service release so I don't get confused by bugs that are already fixed.It's not a matter of policy, it just makes sense.
I can test this issue with an older release. But in order to do that, you would first have to tell me what version you are actually using.
Mike Saltzman"]I'd recommend trying to the latest service release. You can always do a rollback if it doesn't solve the issue. But since I am not getting the problem with the latest service release, either this is an issue that was already fixed, or it's something specific to the environment on your machine(s).tracking down the difference in environments is pretty hard, but updating to the service release is really easy. :)
Hi Sam,
scarleton said:Why do I think the two issues are related? I am speculating that the columnset issue is related because in both cases the Infragistics controls are interrogating the custom business objects. In the columnset case, it was using a incorrect implementation if the ITypedList interface, which I now have corrected. It fits in my mind that with an incorrect implementation of the ITypedList interface (on my part) that the Ingragistics interrogation is going to come up with different "columnset". Add some minor bug in the Ingragistics design time code that uses the ITypedList interface, and the problem shows it ugly face :)
I suppose it's possible, but it still seems unlikely to me that the two issues are related.
scarleton said:(side note, the Form1.cs is marked as having been changed at this point in time and I don't understand why)
I get this, too. I tracked it down and it looks like the form is dirty because the size of the grid is shrinking by 3 pixels every time the form designer opens. This looks like it's probably a DockManager issue. But it does not appear to be related to the exception, since I this is happening for me, but I am still not getting an exception.
scarleton said:I have not tested on the latest code because upgrades effect the whole team, so I am simply working with where we are now.
I'd recommend trying to the latest service release. You can always do a rollback if it doesn't solve the issue. But since I am not getting the problem with the latest service release, either this is an issue that was already fixed, or it's something specific to the environment on your machine(s).tracking down the difference in environments is pretty hard, but updating to the service release is really easy. :)
Another thought on why the two issues are connected:
In both cases, the error ONLY happens when the form is open. With the first problem, the error only happened when you ran the program with the form was open. If you closed the form before running you did not get the error. Same with this new issue, it ONLY happens when the form is open.
I forgot to mention, if I do *NOT* have Form1.cs open, everything works well for me, too.