GNOME Bugzilla – Bug 625702
undoing column deletion creates havoc with autofilter
Last modified: 2012-06-17 04:41:43 UTC
new gnumeric add some data and insert an autofilter in B4:C14 delete columns A:F undo we now have filter combos in columns A:E!
Note that the filter combos work fine, but according to the data menu there is no filter in place!
There is something horribly messed up: static void cb_remove_col_undo (GnmFilter *filter, struct cb_remove_col_undo *r, gpointer data) { while (filter->fields->len <= r->col) gnm_filter_add_field (filter, filter->fields->len); gnm_filter_set_condition (filter, r->col, gnm_filter_condition_dup (r->cond), FALSE); } is called twice (with r->col==0, then r->col==1), which looks like it should attach the two columns that were previously deleted. But hte first time it is called filter->fields->len is already 4, for a filter that should have never more than 2 conditions!
On undo we are first re-inserting 4 rows. These 4 rows end up to be inserted in the filter...
The problem of comment #3 is easy to fix: --- a/src/sheet-filter.c +++ b/src/sheet-filter.c @@ -600,9 +600,11 @@ gnm_filter_attach (GnmFilter *filter, Sheet *sheet) sheet->filters = g_slist_prepend (sheet->filters, filter); sheet->priv->filters_changed = TRUE; - for (i = 0 ; i < range_width (&(filter->r)); i++) - gnm_filter_add_field (filter, i); - + /* Since we might attach a filter whose fields are added later In an und + /* We need to check whether that the range is not empty, see bug #625702 + if (filter->r.start.col <= filter->r.end.col) + for (i = 0 ; i < range_width (&(filter->r)); i++) + gnm_filter_add_field (filter, i); } but this just exposes many other issues that happened to be hidden since the above code added extra columns. On undo we simply overwrite still existing conditions instead of _inserting_ them. If we delete columns overlapping the beginning of a filter we undo it by inserting, but that just shifts the filter. If we delete section of columns that include a filter (as in teh situation above then we set teh filter start to the beginning of that section but never store the true starting value. So there is no way of correcly placing the filter on undo...
This problem has been fixed in the development version. The fix will be available in the next major software release. Thank you for your bug report.