Re: Bug in ctree:resync_selection?
- From: Owen Taylor <otaylor redhat com>
- To: gtk-devel-list redhat com
- Cc: lars gtk org
- Subject: Re: Bug in ctree:resync_selection?
- Date: 28 Jan 2000 12:32:40 -0500
Owen Taylor <email@example.com> writes:
> David Helder <firstname.lastname@example.org> writes:
> > The problem can be reduced to double clicking a node in a ctree (and
> > probably a clist) and then pressing shift causes a seg fault in
> > resync_selection.
> > This is now gtk+ bug #5487 (http://bugs.gnome.org/db/54/5487.html).
> > There is a small test case.
> I've merged this bug with 2051 and 2677, which seem to be the same
> thing or closely related bugs.
> Lars, do you think you'll have chance to look at these bugs
> (It looks like I pointed out 2051 to you some time ago), or
> alternatively, write some documentation about how the selection
> code in CList/CTree is supposed to work?
OK, I'm looked at this some more to see if I could figure out why
the CList was getting into an inconsistent state in the first place.
The culprit seems to be the code in gtk_clist_button_press:
if (event->type == GDK_BUTTON_PRESS)
clist->click_cell.row = -1;
clist->click_cell.column = -1;
clist->drag_button = 0;
the else clause here is harmful, because we get a seequence like:
and clist->drag_button is reset to zero in response to 2BUTTON_PRESS,
so the necessary cleanup isn't done in BUTTON_RELEASE.
However, I have no idea why this code was put in there in the first
place, and doing a thorough check of clist/ctree functionality after
removing it isn't really practical so I'll just put the sanity checks
into the resync_selection and a FIXME here.
] [Thread Prev