From 3f2c88fd0f1c284881b5d63655850619017185d9 Mon Sep 17 00:00:00 2001 From: Federico Mena Quintero Date: Wed, 31 Oct 2001 12:49:54 +0000 Subject: If a query is not in progress, just retag the whole thing. An event may 2001-10-31 Federico Mena Quintero * gui/gnome-cal.c (dn_query_obj_updated_cb): If a query is not in progress, just retag the whole thing. An event may change dates and tag_calendar_by_comp() would not know how to untag the old dates. Fixes bug #10220. * pcs/query.c (start_query_cb): Connect to the backend's "obj_updated" and "obj_removed" signals here instead of in query_construct(). If a query is started while another one is notifying of an update, these signal connections would get appened to the running signal (the one that triggered the notification about an update) and the new signal handlers would also get called. We are really not interested in updates before we populate the query, because we'll catch the changes anyways. svn path=/trunk/; revision=14533 --- calendar/gui/gnome-cal.c | 10 ++++++++++ 1 file changed, 10 insertions(+) (limited to 'calendar/gui') diff --git a/calendar/gui/gnome-cal.c b/calendar/gui/gnome-cal.c index 1912068208..98c01e6372 100644 --- a/calendar/gui/gnome-cal.c +++ b/calendar/gui/gnome-cal.c @@ -303,6 +303,16 @@ dn_query_obj_updated_cb (CalQuery *query, const char *uid, gcal = GNOME_CALENDAR (data); priv = gcal->priv; + /* If this is an update that is not part of an ongoing query, we have to + * retag the whole thing: an event may change dates and the + * tag_calendar_by_comp() below would not know how to untag the old + * dates. + */ + if (!query_in_progress) { + update_query (gcal); + return; + } + status = cal_client_get_object (priv->client, uid, &comp); switch (status) { -- cgit v1.2.3