Hello
> > > Heh... yes, I have that feeling too. I just didn't want to made > design-level changes (and even if I did want, I didn't dare since this > is my first day with the winforms source code). > However, I can explain how I see the problem so you guys decide if > deeper changes are necesary. > > The ListView problem: > > 1) When a new SubItem is added, the ListViewSubItem constructor sets the > SubItem text. > 2) Text.set in the SubItem Text property calls Invalidate(Bounds). > 3) Bounds.get calls GetBounds() and this calls GetItemLocation(). > 4) GetItemLocation() uses the items_location[] array. > > Now, items_location[] is set to an initial lenght of [16] by the > ListView constructor, and extended by AdjustItemsPositionArray if needed. > AdjustItemsPositionArray is only called by CalculateListView, which is > called only before a redraw. > > So, if you add a 17th item before a redraw, you get an index out of > bounds at ListView.GetItemLocation(). > > I think the problem here is that Invalidate() ends up usign > items_location[], which is only calculated when redrawing. That doesn't > seem to make sense sometimes, since Invalidate() happens _before_ the > redraw. Actually the sequence is: Redraw () -> Invalidate () -> Update (Paint) The thing is is that Redraw (and thus AdjustItemsPositionArray) is _always_ called before Invalidate or Update (or Paint, which actually requests Items count info and more). So this should be a problem _apparently_. The problem anyway seems to be an out of synch state between them. The problem is: I can't reproduce it. Do you have a sample case? Carlos. _______________________________________________ Mono-winforms-list maillist - Mono-winforms-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-winforms-list