After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 625702 - undoing column deletion creates havoc with autofilter
undoing column deletion creates havoc with autofilter
Status: RESOLVED FIXED
Product: Gnumeric
Classification: Applications
Component: GUI
git master
Other Linux
: Normal normal
: ---
Assigned To: Jody Goldberg
Jody Goldberg
Depends on:
Blocks:
 
 
Reported: 2010-07-31 03:16 UTC by Andreas J. Guelzow
Modified: 2012-06-17 04:41 UTC
See Also:
GNOME target: ---
GNOME version: ---



Description Andreas J. Guelzow 2010-07-31 03:16:31 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!
Comment 1 Andreas J. Guelzow 2012-06-15 16:35:50 UTC
Note that the filter combos work fine, but according to the data menu there is no filter in place!
Comment 2 Andreas J. Guelzow 2012-06-17 00:49:33 UTC
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!
Comment 3 Andreas J. Guelzow 2012-06-17 02:09:29 UTC
On undo we are first re-inserting 4 rows. These 4 rows end up to be inserted in the filter...
Comment 4 Andreas J. Guelzow 2012-06-17 03:19:20 UTC
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...
Comment 5 Andreas J. Guelzow 2012-06-17 04:41:43 UTC
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.