Question

I have a public property set in my form of type ListE<T> where:

public class ListE<T> : IList<T>, ICollection<T>, IEnumerable<T>, IList, ICollection, IEnumerable

Yeah, it's a mouthful, but that's what the Designer requires for it to show up as an editable collection in the Properties window. Which it does! So, I click the little [..] button to edit the collection, and then click Add to add an item to the collection.

Arithmetic operation resulted in an overflow.

Now, this is a very basic List, little more than an expanding array. The only part that comes close to arithmetic in the whole thing is in the expand function, and even that uses a left shift rather than a multiplication, so that won't overflow. This all makes me think that this exception is being raised inside the Designer, perhaps caused by some small inattention to implementation detail on my part, but I can't find a way to test or debug that scenario. Does anyone have any smart ideas?

EDIT: Yes, I can use the property successfully, well even manually, ie. in the OnLoad handler, and I suppose that's what I'll have to resort to if I can't get this working, but that wouldn't be ideal. :(

Was it helpful?

Solution

I can't understand what's motivating you to attempt to reinvent the List<T> wheel in that way, but to answer your question: I would add a line "System.Diagnostics.Debugger.Break()" to the constructor of your class.

Then try to use it in the designer, and you'll get a popup asking you if you want to attach a debugger. Attach a second instance of Visual Studio as a debugger, and you'll be able to set some breakpoints in your code and start debugging.

OTHER TIPS

One place to start would be that it may be doing math with your ListE`1::Count property. If that has some subtle flaw (i.e. it is more complicated than return this.innerList.Count) it could be causing the designer to arithmetic overflow on some operation. Normally arithmetic overflows do not occur unless specifically asked for using the

checked
{
   // ...
}

syntax.

You don't have to add the Debugger.Break(); call to your code to debug it. You can just open a different instance of VS and attach to the one that you using it in and you should be able to debug it with no issues (just make sure that you have the symbols loaded).

Licensed under: CC-BY-SA with attribution
Not affiliated with StackOverflow
scroll top