Re: Bug in ctree:resync_selection?

[Lars Hamann <lars gtk org>]

Hi Owen,

On Fri, Jan 28, 2000 at 12:32:40PM -0500, Owen Taylor wrote:

> > 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)
> 	    {
>                 [...]
> 	    }
> 	  else
> 	    {
> 	      clist->click_cell.row = -1;
> 	      clist->click_cell.column = -1;
> 
> 	      clist->drag_button = 0;
> 	      remove_grab (clist);
> 	    }
> ======
> 
> the else clause here is harmful, because we get a seequence like:
> 
>   BUTTON_PRESS
>   2BUTTON_PRESS
>   BUTTON_RELEASE
> 
> 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.

The main problem was a missing line which resets clist->anchor to -1
in case of GTK_SELECTION_SINGLE/MULTIPLE when event-type is 
GDK_BUTTON2_PRESS. I've changed that. I've also added an extra check
in resync_selection, since it's only needed in the extended selection
mode.

bye,
  Lars